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Executive  Summary 


Organi2ations  need  records  to  carry  out  their  business  activities  and  to 
document  actions  and  decisions.  Today,  most  organizations  increasingly 
manage  work  and  make  decisions  on  the  basis  of  electronic  information. 
Many  transactions  that  were  once  paper-based  are  now  being  performed 
electronically,  as  networked  computer  systems  that  once  played  a  purely 
supportive  role  have  moved  to  center  stage.  However,  with  the  shift  from 
paper  to  digital  information,  many  organizations  find  that  their  current 
electronic  records  are  not  sufficient  to  support  the  evidentiary  needs  of 
their  business  functions.  Others  face  the  problem  of  linking  documents 
created  in  different  forms  and  formats  to  business  transactions.  Many 
organizations  are  in  danger  of  losing  access  to  records  stored  in  personal 
computers,  e-mail  boxes,  or  personal  local  area  network  directories.  From 
an  archival  perspective,  which  focuses  on  long-term  societal  and 
organizational  needs,  problems  like  these  mean  records  of  enduring  value 
are  partially  or  entirely  lost. 

Without  question,  organizations  need  electronic  records  that  are  reliable 
and  authentic,  usable  for  multiple  purposes,  and  accessible  over  time  for 
both  business  and  secondary  uses.  Unfortunately,  traditional  system  design 
methodologies  do  not  give  adequate  attention  to  the  creation,  integration, 
management,  and  preservation  of  electronic  records.  In  many  cases, 
redundant  paper  systems  must  be  maintained  or  substantial  additional 
resources  must  be  expended  in  order  to  address  records  management 
requirements  after  information  systems  have  been  implemented. 


Project  Overview 


The  project  described  in  this  report  was  an  attempt  to  develop  a  practical 
way  to  incorporate  essential  electronic  records  requirements  into  the  design 
of  new  information  systems.  Funded  in  large  part  by  a  research  grant  from 
the  National  Historical  Publications  and  Records  Commission  (NHPRC), 
the  project  was  conducted  from  1996  to  1998  through  a  partnership 
between  the  New  York  State  Archives  and  Records  Admimstration  (SARA) 
and  the  Center  for  Technology  in  Government  (CTG).  The  project  team 
included  staff  of  the  NYS  Adirondack  Park  Agency,  eight  corporate 
partners  led  by  Intergraph  Corporation,  and  University  at  Albany  faculty 
and  graduate  students. 

In  recent  years,  significant  theoretical  work  has  been  done  in  the  area  of 
electronic  records  management;  however,  Utde  has  been  translated  into 
practical  implementable  solutions.  This  project  was  designed  to  bridge  the 
gap  between  theory  and  practice  by  producing  generahzeable  tools  that  link 
business  objectives  to  sound  records  management  practices.  This 
connection  can  be  understood  most  readily  at  the  business  process  level 
where  workflow,  information  flow,  and  service  delivery  come  together. 
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The  project  integrated  and  biailt  upon  several  existing  bodies  of  knowledge: 
electronic  recordkeeping  and  archival  theory  and  practice,  business  process 
improvement  and  reengineering  (BPI/BPR)  methodologies,  and  system 
development  methodologies.  The  work  was  guided  by  four  objectives: 

♦  Create  a  set  of  general  functional  requirements  for  electronic 
recordkeeping. 

♦  Create  a  practical  tool  to  support  the  integration  of  application- specific 
electronic  recordkeeping  requirements  into  the  design  of  networked 
computing  systems. 

♦  Develop  and  test  a  prototype  system  which  reflects  the  use  of  the  tool. 

♦  Evaluate  the  effectiveness  of  the  functional  requirements  and  the  tool. 

The  project  produced  two  practical  products: 

Functional  Requirements  to  Ensure  the  Creation,  Maintenance,  and 
Preservation  of  Electronic  Records  integrates  theoretical  and  practical 
work  in  the  areas  of  electronic  recordkeeping  and  archives.  It  defines 
“record”  as  “the  complete  set  of  documentation  required  to  provide 
evidence  of  a  business  transaction”  and  comprises  three  requirements: 

♦  Records  Capture  Requirement  -  Records  are  created  or  captured 
and  identified  to  support  the  business  process  and  meet  aU 
recordkeeping  requirements  related  to  the  process. 

♦  Records  Maintenance  and  Accessibility  Requirement  - 
Electronic  records  are  maintained  so  that  they  are  accessible  and 
retain  their  integrity  for  as  long  as  they  are  needed. 

♦  System  Reliability  Requirement  -  A  system  is  administered  in 
accordance  with  best  practices  in  the  information  resource 
management  (IRM)  field  to  ensure  the  reliability  of  the  records  it 
produces. 

The  Records  Requirements  Analysis  and  Implementation  Tool 
(RRAIT).  The  RRAIT  translates  the  Functional  Requirements  into  a 
series  of  questions  or  cues  that  assist  in  the  comprehensive  identification 
of  records  management  requirements  during  the  design  of  a  new 
information  system.  It  is  comprised  of  two  components: 

♦  Records  Requirements  Elicitation  Component  (RREC) 

facilitates  the  identification  of  records  management  requirements 
during  business  process  improvement  and  systems  analysis 
activities.  The  RREC  is  divided  into  three  levels.  The  Business 
Process  Level  addresses  the  Records  Capture  Requirement  and 
focuses  on  records  requirements  associated  with  the  business 
process  that  is  to  be  automated.  The  Record  Level  addresses  the 
Records  Maintenance  and  Accessibility  Requirement  and  focuses 
on  internal  and  external  use  and  access  to  the  record.  The  System 
Level  addresses  the  System  Reliability  Requirement  and  focuses  on 


Page  8 


Center  for  Technology  in  Government 


those  records  requirements  associated  with  technology,  system 
administration,  and  system  configuration  alternatives. 

♦  Records  Requirements  Implementation  Component  (RRIC) 
focuses  on  the  identification  of  management,  policy,  and 
technology  strategies  that  address  the  records  management 
requirements  once  they  have  been  identified  by  the  Business 
Process,  Record,  and  System  Levels  of  the  RREC. 

Using  information  gathered  from  interviews,  business  process 
improvement  activities,  and  the  use  of  the  RRAIT,  a  prototype  system  was 
developed  at  the  New  York  State  Adirondack  Park  Agency  (APA).  APA 
was  interested  in  improving  the  land  use  permit  process  and  increasing 
access  to  records  in  order  to  reduce  transaction  turnaround  time,  increase 
staff  productivity,  and  demonstrate  predictability  and  consistency  in  its  land 
use  decisions.  The  prototype  system  is  a  networked  document 
management  and  workflow  system  capable  of  accessing,  analyzing,  and 
capturing  information  from  the  Agency’s  geographic  information  system 
(GIS).  It  has  the  capacity  to  support  a  fully  electronic  record  including  the 
archiving  of  that  record.  The  prototype  served  as  a  mechanism  for 
identifying  both  the  records  requirements  and  management  and  poKcy 
strategies  to  support  them  in  a  full  system  implementation.  It  was 
evaluated  in  terms  of  agency  benefits  and  costs,  the  degree  to  which  the 
original  set  of  records  requirements  was  addressed,  and  the  degree  to  which 
the  tools  met  criteria  for  generalizeability  to  other  organizations. 


Lessons  learned 


Business  processes  provide  a  common  focus  for  records  managers, 
archivists,  technologists,  and  business  managers.  A  business  process 
perspective  ties  discussions  of  records  management  issues  to  work  that  is 
critical  to  an  organization.  By  linking  records  management  issues  to 
business  processes,  the  tools  provide  a  common  language  for  improved 
communication  between  records  management  professionals  and  other 
practitioners.  Program  managers  indicated  that  this  manner  of  presentation 
enabled  them  to  understand  the  importance  of  records  management 
requirements  in  terms  of  the  issues  that  are  critical  to  them  in  conducting 
their  work.  For  technologists,  the  tools  could  be  seamlessly  integrated  into 
the  business  process  improvement  phase  of  system  design  and  generated 
requirements  that  led  to  well-defined  system  features  and  data 
requirements. 

Comprehensive  records  management  requirements  directly  support 
business  objectives.  The  tools  prompt  participants  to  identify  a 
comprehensive  set  of  records  management  requirements  associated  with  a 
business  process.  The  Business  Process  Level  of  the  RREC  helps  identify 
the  specific  record  components  that  must  be  captured  at  each  step  during 
the  course  of  a  transaction.  It  also  ties  each  component  to  specific  legal  or 
professional  standards  or  organizational  practices.  The  Record  Level 
addresses  the  need  for  access  to  records  over  time.  The  RRIC  can  then  be 
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used  to  identify  technology  and  other  mechanisms  to  ensure  that  that 
records  are  appropriately  captured  and  that  they  remain  accessible  for  both 
current  and  future  use.  Moreover,  the  tools  are  capable  of  identifying  all 
authenticity  requirements  tied  to  the  business  process  and  they  help  identify 
the  diversity  of  forms  and  formats  that  a  system  must  be  able  to 
accommodate  in  order  to  assemble  a  complete  record.  These  requirements 
are  not  Hmited  to  "recordkeeping’  needs;  they  are  integral  to  the  business 
process  itself. 

Current  and  future  access  needs  can  be  specified  and  accommodated 
in  system  design.  The  tools  have  the  ability  to  deal  with  both  internal  and 
external  primary  and  secondary  access  to  records.  They  also  call  attention 
to  long-term  access  issues  such  as  migration  strategies  and  meta  data  that 
are  best  addressed  at  the  initial  system  design  stage.  The  Business  Process 
and  Record  Levels  of  the  RREC  support  the  identification  of  access  needs 
from  the  perspective  of  internal  users  during  a  business  transaction  as  well 
as  internal  and  external  access  needs  after  the  transaction  has  been 
completed.  The  questions  are  designed  to  identify  the  components  of  a 
record  required  by  each  of  these  user  types  as  well  as  their  preferred  or 
required  access  methods. 

In  system  design,  focus  first  on  business  needs  and  records  that 
support  them;  then  focus  on  technology.  In  general,  the  use  of  the  tools 
shifts  the  focus  of  system  design  and  development  away  from  technology 
and  toward  the  capture,  maintenance,  and  ongoing  use  of  business  records. 
The  tools  embed  the  importance  of  the  record  into  the  system 
development  process  from  the  perspective  of  both  users  and  system 
developers.  Records  management  requirements  based  on  business  process 
analysis  are  directly  translated  into  user  and  system  requirements.  The 
responses  to  the  questions  in  the  Business  Process  and  System  Levels  of 
the  RREC  are  easily  communicated  to  system  developers  in  terms  of 
technical  specifications.  In  addition,  the  questions  that  focus  on  the 
documents  that  comprise  a  record  and  on  internal  and  external  access  to 
records  are  readily  translated  into  data  model  specifications. 

Focus  on  system  functionality  before  choosing  specific  technologies. 

The  tools  help  organizations  identify  the  functionality  that  is  required  in  a 
system  to  support  records  management  requirements,  and  emphasize 
technology  solutions  that  maximize  inter-operability  and  adherence  to 
standards.  They  do  not  address  the  actual  selection  of  hardware  and 
software  to  provide  the  necessary  functionality.  This  selection  must  be 
based  on  many  factors  such  as  existing  infrastructure  (both  technical  and 
organizational),  cost,  and  expected  benefits.  We  strongly  recommend  that 
technology  awareness  activities  be  conducted  in  conjunction  with  the  use 
of  the  tools.  Product  reviews,  vendor  presentations,  and  conferences 
focused  on  technology  applications  are  all  ways  to  increase  awareness  of 
technology  capabilities  and  limitations  among  the  staff  who  will  work  with 
the  new  system.  These  kinds  of  activities  increase  understanding  of  the 
strengths  and  weaknesses  of  various  technology  choices. 
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Supporting  policies  and  management  practices  are  essential,  but 
challenging,  components.  The  RRIC,  with  its  focus  on  implementation, 
highlights  the  importance  of  policy  and  management  strategies  —  critical 
elements  that  often  receive  little  or  no  attention  in  system  development 
efforts.  The  tools  facilitate  the  identification  of  related  management  and 
policy  strategies,  such  as  the  range  of  user  permissions  and  definition  of  a 
minimum  legal  record.  Policies  and  practices  ensure  the  entire  organization 
is  working  in  concert  with  the  records  management  requirements  that  are 
built  into  the  electronic  system.  In  most  organizations,  these  issues  present 
the  most  difficulty  because  their  content  and  execution  depend  on 
organizational  consensus  about  the  way  work  should  be  done. 

All  record  users  need  to  participate  in  the  identification  of 
requirements.  One  of  the  most  critical  factors  for  effective  use  of  the 
tools  is  getting  the  right  people  to  answer  the  questions.  AH  primary  and 
secondary  users  of  the  records  that  wiU  be  created  and  maintained  by  an 
information  system  should  be  represented  in  the  elicitation  of  the  records 
requirements.  Other  players  who  may  not  be  direct  records  users,  such  as 
legal  staff  and  executives,  need  to  be  involved  in  the  development  of 
management  and  policy  strategies  that  will  support  users.  Not  every  group 
needs  to  be  involved  in  the  entire  process,  but  each  needs  to  participate 
actively  at  the  appropriate  points  so  that  aU  user  needs  are  identified  and 
incorporated  into  the  system  design. 

The  records  requirements  tools  can  be  used  in  a  variety  of  ways.  The 

tools  provide  a  sound  framework  for  the  identification  of  records 
management  requirements  that  can  be  modified  to  suit  the  setting  in  which 
they  are  used.  While  we  strongly  recommend  that  the  Business  Process 
Level  of  the  RREC  be  used  in  conjunction  with  business  process  analysis 
or  improvement  activities,  the  questions  in  the  other  sections  can  be  posed 
using  a  variety  of  methods  such  as  surveys  and  interviews.  The  manner  in 
which  the  questions  are  asked  and  answered  can  be  tailored  for  use  across 
different  organizational  contexts.  They  should  be  selected  for  their 
compatibility  with  the  organization’s  skills  and  time  schedules,  and  their 
ability  to  minimize  the  total  cost  of  the  information  collection  process. 

Awareness  and  willingness  to  change  are  preconditions  for  success. 

Perhaps  the  biggest  weakness  of  the  tools  is  the  pre-condition  for  their  use. 
That  is,  an  organization  must  first  recognize  the  importance  of  its  business 
records  and  the  costs  and  risks  associated  with  ignoring  them.  Without  this 
foundation,  it  is  unlikely  that  an  organization  wUl  invest  the  time  and 
attention  to  detail  that  the  tools  demand.  While  the  tools  support  the 
comprehensive  identification  of  records  management  requirements  and 
mechanisms  for  addressing  them,  the  degree  to  which  they  are 
implemented  depends  on  the  organization’s  readiness  and  willingness  to 
change.  Change  means  more  than  new  information  systems;  it  requires 
supporting  management  and  policy  strategies  as  well  as  an  understanding 
of  the  degree  to  which  the  requirements  can  be  addressed  by  the  chosen 
technologies.  In  sum,  while  the  tools  support  the  identification  of 
requirements,  the  factors  that  surround  their  implementation  determine  the 
ultimate  level  of  success. 
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Chapter  1 .  Project  Overview 


Globalization,  an  unabated  quest  for  efficiency,  and  public  demands  for 
high  quality  services  are  driving  organizations  in  every  sector  to  improve 
the  way  they  conduct  business  and  serve  theit  customers.  Technology  is  a 
key  factor  in  this  trend  and  its  rapid  advance  has  stimulated  major  changes 
in  the  way  organizations  work  internally  and  how  they  interact  with  their 
suppliers,  partners,  and  customers. 

This  thirty-year  trend  began  with  mainframe  computing  in  the  1970s  when 
much  operational  and  financial  data  began  to  be  created  and  managed  in 
digital  form.  During  the  1980s,  the  widespread  use  of  microcomputers  led 
most  office  documents  to  be  created  electronically.  However,  the 
installation  of  local  and  wide  area  networks  in  the  late  1980s  and  early 
1990s,  along  with  the  recent  advent  of  the  Internet  and  World  Wide  Web, 
have  created  the  most  rapid  and  far-reaching  changes  in  how  organizations 
communicate  and  conduct  business.  For  example,  e-mail  is  replacing  the 
telephone  as  the  communication  means  of  choice  for  conducting  internal 
business;  intranets,  not  interoffice  mail,  are  offering  widespread,  secure 
communications  for  a  wide  range  of  business  functions.  Today,  many 
organizations  are  taking  advantage  of  such  technologies  as  electronic  data 
interchange,  digital  imaging,  geographic  information  systems,  and 
groupware  to  support  paperless  transactions.  These  technologies  have  a 
substantial  impact  on  the  ability  of  organizations  to  create,  manage,  and 
use  records  to  support  legal  responsibilities  and  business  needs. 

Within  both  the  public  and  private  sectors,  decisions  are  increasingly  made 
on  the  basis  of  information  that  appears  on  employee  computer  screens. 
Many  transactions  that  were  once  paper-based  are  now  being  performed 
electronically,  as  networked  computer  systems  that  once  played  a  purely 
supportive  role  have  moved  to  center  stage.  This  shift  away  from  reliance 
on  paper-based  transactions  has  compelled  many  organizations  to  rethink 
the  way  they  perform  recordkeeping  functions.  If  organizational  decisions 
are  to  be  based  on  the  information  contained  in  these  networked  systems, 
then  we  need  to  be  sure  that  the  information  is  identified,  collected,  and 
preserved  in  accordance  with  sound  electronic  recordkeeping  practices. 

But  what  exactly  are  "sound  electronic  recordkeeping  practices?’  And  how 
do  you  go  about  implementing  them  in  your  organization?  In  truth,  the 
term  denotes  far  more  than  the  basic  maintenance  of  electronic  data.  It 
also  refers  to  the  development  and  implementation  of  sound  management 
and  poKcy  structures  to  support  organizational  recordkeeping  requirements 
commensurate  with  attendant  business  needs  and  capable  of  preserving  the 
integrity  of  electronic  information  for  both  current  and  future  uses.  In 
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order  to  conduct  business  electronically  and  to  take  full  advantage  of  new 
technologies,  organizations  need  to  create,  manage,  and  maintain  electronic 
records  that  are: 

♦  accessible  over  time  for  business  and  secondary  uses 

♦  reliable  and  authentic  -  to  stand  up  in  legal  and  administrative 
forums 

♦  usable  for  multiple  purposes 


The  current  environment 

As  a  result  of  the  trends  toward  electronic  information,  many  organizations 
are  in  danger  of  losing  access  to  records  stored  in  personal  computers,  e- 
mail  boxes,  or  personal  local  area  network  directories.  Consequently,  many 
find  that  their  electronic  records  do  not  meet  their  evidentiary  needs  and 
they  are  therefore  forced  to  maintain  duplicative  paper  files.  Others  face 
the  problem  of  linking  documents  created  in  different  forms  and  formats 
to  business  transactions.  For  example,  a  government  agency  that  issues 
land  use  permits  may  need  to  access  a  paper  file  folder,  e-mail  messages, 
word  processing  files,  and  maps  and  other  geographic  information  in  order 
to  obtain  a  complete  record  of  a  permit  transaction. 

The  absence  or  loss  of  electronic  records  takes  a  serious  toll  on  both  the 
creating  organization  and  society,  particularly  when  records  of  enduring 
social  and  cultural  value  are  lost  to  future  generations.  In  fact,  substantial 
and  damaging  losses  of  electronic  records  have  been  documented: 

♦  Ontario  Hydro’s  nuclear  power  plant  near  Toronto  could  find  no 
record  of  a  crucial  reactor  sealing  ring  that  had  suddenly  begun  to 
wear  out  several  years  earlier  than  expected.  The  records  manager 
of  the  huge  provincial  utility  blamed  the  lost  records  on  the 
recently  installed  computer  network  and  worker  unfamiliarity  with 
the  company’s  new  practices  for  storing  documents. 

♦  The  US  National  Aeronautics  and  Space  Administration  (NASA) 
recently  discovered  that  some  1.2  million  magnetic  tapes  of 
observations  created  during  three  decades  of  space  flight  could  not 
be  read  or  sometimes  even  found.  Many  tapes  were  uncataloged; 
heat  or  floods  had  damaged  others.  Many  could  not  be  associated 
with  the  mission,  spacecraft,  or  computer  system  which  created 
them.  NASA  officials  estimate  it  will  take  millions  of  dollars  and 
years  of  detective  work  to  link  these  files  to  thek  missions  and 
then  decode  the  information  so  that  hardware  and  software  now  in 
use  can  read  them. 
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♦  In  the  late  1960s,  New  York  State  and  Cornell  University 

undertook  the  Land  Use  and  Natural  Resources  Inventory  Project 
(LUNR).  LUNR  created  a  computerized  map  and  primitive 
geographic  information  system  of  New  York  State  depicting 
patterns  of  land  usage  and  natural  resources.  It  was  created  by 
superimposing  a  matrix  over  aerial  photographs  of  the  entire  state 
and  coding  each  cell  according  to  its  predominant  features.  In  the 
mid«1980s,  the  New  York  State  Archives  obtained  copies  of  the 
tapes  containing  the  data  from  the  LUNR  inventory  along  with  the 
original  aerial  photographs  and  several  thousand  mylar 
transparencies.  State  Archives  staff  attempted  to  preserve  the 
LUNR  tapes,  but  the  problems  proved  insurmountable.  The 
LUNR  project’s  customized  software  programs  were  not  saved 
with  the  data  and  the  hardware  and  operating  system  needed  to  run 
the  software  were  no  longer  available. 

From  an  archival  perspective,  which  focuses  on  long-term  societal  and 
organizational  needs,  problems  like  these  mean  records  of  enduring  value 
are  partially  or  entirely  lost.  Perhaps  more  importantly,  organizations  are 
finding  that  their  current  electronic  records  are  not  sufficient  to  support  the 
ongoing  needs  of  their  business  functions.  In  many  cases,  redundant  paper 
systems  must  be  maintained  or  substantial  additional  resources  must  be 
expended  in  order  to  address  records  management  requirements  after 
information  systems  have  been  implemented.  Therefore,  organizations 
need  immediate  and  specific  solutions  and  tools  that  will  help  them 
integrate  electronic  records  management  requirements  into  their 
applications  and  business  processes.  Unfortunately,  traditional  system 
design  methodologies  do  not  give  adequate  attention  to  the  creation, 
integration,  management,  and  preservation  of  electronic  records.  The 
project  described  in  this  report  was  an  attempt  to  develop  a  practical  way  to 
incorporate  essential  electronic  records  requirements  into  the  design  of 
new  information  systems. 


Center  for  Technology  in  Government  project 

The  National  Historical  Publications  and  Records  Commission  (NHPRC) 
assists  in  national  efforts  to  identify,  preserve,  and  provide  public  access  to 
records  through  research  grants  made  to  state  and  local  archives,  colleges 
and  universities,  libraries,  historical  societies,  and  other  nonprofit 
organizations  throughout  the  United  States. 

Responding  to  the  growing  need  for  practical  tools  to  support  government 
electronic  recordkeeping,  the  State  Archives  and  Records  Administration 
(SARA)  and  the  Center  for  Technology  in  Government  (CTG)  jointly 
submitted  a  proposal  to  NHPRC  in  1995  to  conduct  a  project  entitled 
Models  for  Action:  Developing  Practical  Approaches  to  Electronic  Records  Management 
and  Preservation.  SARA  and  CTG,  long-time  partners  in  supporting 
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government  agencies  in  their  use  of  information  and  technology,  proposed 
to  develop  a  set  of  practical  tools  that  integrate  records  management 
requirements  into  the  system  design  process.  NHPRC  awarded  a  two-year 
research  grant  to  conduct  the  project. 

The  CTG-SARA  proposal  recognized  that  organizations  increasingly  rely 
on  networked  systems  to  perform  or  support  business  processes.  In  fact, 
customized  application  systems  such  electronic  commerce  and  office 
automation  systems  that  involve  databases,  e-mail,  and  word  processing 
have  assumed  an  integral  role  within  many  organizations.  However,  most 
organizations  lack  adequate  tools  to  manage  the  number  and  variety  of 
electronic  records  in  a  networked  environment.  Since  it  is  both  logical  and 
critical  that  organizations  incorporate  effective  electronic  records 
management  practices  into  the  normal  course  of  business,  the  proposal 
argued  that  these  practices  must  be  addressed  at  the  system  development 
stage.  In  this  way,  system  features  and  functionality  will  capture,  maintain, 
and  ensure  access  to  electronic  records  and,  ideally,  associated  management 
and  poKcy  issues  will  be  addressed. 

Significant  theoretical  work  has  been  done  in  the  area  of  electronic  records 
management  and  several  organizations  have  attempted  to  implement 
practical  solutions.  This  work  can  be  categorized  into  three  types: 

♦  NHPRC-funded  or  similar  projects  focused  on  records 
management  and  archival  issues 

♦  Initiatives  by  archival,  records  management,  or  information 
resource  management  institutions  or  units  focused  on  identifying 
functional  requirements  for  recordkeeping  as  part  of  their 
organizational  missions 

♦  System  development  initiatives  that  seek  to  implement 
requirements  for  electronic  recordkeeping 

Litde  of  the  theoretical  work  that  has  been  done  in  the  area  of  electronic 
records  management  has  been  translated  into  practical  implementable 
solutions.  Further,  the  system  development  initiatives  that  have  included 
consideration  of  electronic  recordkeeping  requirements  have,  for  the  most 
part,  resulted  in  organization-specific  document  management  requirements. 
These  requirements  are  focused  primarily  on  technical  aspects  of  system 
development  and  implementation  and  neglect  to  consider  the  necessary 
supporting  management  and  policy  strategies.  We  believe  these  efforts  have 
had  limited  value  because  they  lack  a  generahzeable  operational  connection 
between  records  management  practices  and  the  achievement  of  an 
organization’s  business  objectives. 

The  tools  developed  by  this  project  were  designed  to  bridge  that  gap  by 
producing  practical  generalizeable  tools  to  support  the  identification  of 
organization-specific  business  objectives  and  records  management  practices. 
This  connection  can  be  understood  most  readily  at  the  business  process  level 
where  workflow,  information  flow,  and  service  delivery  come  together. 
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Project  objectives 


The  primary  goal  of  the  project  was  to  develop  and  promote  practical  tools 
to  assist  government  agencies  and  business  organizations  in  addressing 
electronic  records  management  and  archival  requirements  as  they  develop 
networked  computing  and  communications  applications.  Project  activities 
were  focused  in  four  areas: 

♦  Creation  of  a  set  of  general  functional  requirements  for  electronic 
recordkeeping 

♦  Creation  of  a  practical  tool  to  support  the  integration  of 
application-specific  electronic  recordkeeping  requirements  into  the 
design  and  development  of  networked  computing  systems 

♦  Development  and  testing  of  a  prototype  networked  workflow  and 
document  management  system  which  reflects  the  use  of  the  tool 

♦  Evaluation  of  the  effectiveness  of  the  functional  requirements  and 
the  tool  in  enhancing  the  essential  recordkeeping  capabilities  of  the 
prototyped  application. 

In  order  to  be  generalizeable  to  other  settings,  the  tools  and  techniques 
needed  to  be  flexible  enough  to  apply  to  diverse  business  processes  and 
organizations.  Therefore,  they  needed  to  meet  the  following  criteria: 

♦  Focus  attention  on  creating  and  managing  usable  electronic  records 
as  systems  are  developed 

♦  Assist  in  building  adequate  electronic  records  management 
functionality  into  these  systems 

♦  Ensure  that  the  electronic  records  created  meet  evidentiary  as  well 
as  informational  needs 

♦  Ensure  that  electronic  records  are  captured  and  accessible  to  all  users 

♦  Ensure  that  documents  created  in  different  forms  and  formats  are 
linked  to  business  transaction  requirements 

♦  Assist  in  the  identification  and  integration  of  supportive  but 
essential  records  management  policies  and  management  practices 


Project  participants 

In  addition  to  CTG  and  SARA,  the  project  team  included  staff  from  the 
Adirondack  Park  Agency;  a  project  advisory  committee  of  records 
management  experts  representing  a  wide  range  of  academic,  government, 
and  private  sector  entities;  faculty  and  students  from  the  University  at 
Albany;  and  a  number  of  corporate  partners.  A  list  of  the  project 
participants  is  provided  in  Appendix  A. 
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The  New  York  State  Adirondack  Park  Agency 


The  New  York  State  Adirondack  Park  Agency  (APA)  is  mandated  by  its 
enabling  statute,  the  Adirondack  Park  Agency  Act  (Executive  Law,  Article 
27)  to  formulate  land  use  development  regulations  and  long-range  policy 
for  the  6-miIlion  acre  Adirondack  Park.  The  3.5  million  acres  of  private 
lands  in  the  Park  are  governed  by  the  Adirondack  Park  Land  Use  and 
Development  Plan,  adopted  by  the  NYS  Legislature  in  1973.  This  plan 
classifies  the  Park’s  private  lands  into  six  categories  according  to  their  ability 
to  withstand  development  without  significant  adverse  environmental 
impacts.  The  number  of  buildings  allowed  varies,  depending  on  the  private 
land  use  classification.  Further,  depending  on  the  classification  of  the 
private  land  parcel  on  which  it  is  proposed,  permits  for  many  types  of 
development  are  required.  In  participating  in  this  project,  APA  sought  to 
improve  the  land  use  permit  process  in  order  to  reduce  transaction 
turnaround  time,  increase  staff  productivity,  and  demonstrate  predictability 
and  consistency  in  its  land  use  decisions.  The  land  use  permitting  process 
was  an  ideal  test  case  for  the  project  tools  since  it  needs  to  integrate 
information  from  diverse  physical  and  digital  formats,  and  is  highly 
dependent  on  the  ability  to  identify  and  retrieve  information  about  previous 
Agency  actions.  A  wide  range  of  Agency  staff  worked  with  CTG  and 
SARA  in  a  series  of  activities  including  individual  interviews,  surveys, 
workshops,  technical  assessments,  training,  prototype  installation  and  use, 
and  evaluation. 


Advisory  Committee 

The  Project  Advisory  Committee,  drawn  from  the  public,  private,  and 
academic  sectors,  met  three  times  during  the  project.  During  these 
meetings  the  Advisory  Committee  reviewed  project  goals  and  deliverables 
and  provided  comments  and  recommendations  reflecting  their  diverse 
perspectives  and  disciplines.  Committee  members  were  provided  with 
proposed  project  plans,  draft  products,  and  other  materials  for  review  prior 
to  meetings.  The  Advisory  Committee  was  composed  of  information  and 
electronic  records  management  practitioners  from  a  variety  of  professional 
settings,  including  government,  banking,  health  care,  and  insurance.  The 
individual  members  of  the  Project  Advisory  Committee  are  listed  in 
Appendix  A. 


Academic  Partners 

A  faculty  member  from  the  Department  of  Public  Administration  and  Policy 
at  the  University  at  Albany,  conducted  a  two-day  workshop  to  evaluate  the 
costs  and  benefits  of  an  electronic  land  use  permit  system  at  APA.  Several 
graduate  assistants  firom  Computer  Science,  Public  Administration, 
Information  Science,  and  Management  Science  and  Information  Systems 
participated  as  members  of  the  project  team  as  well.  The  graduate  assistants 
participated  in  the  development  and  implementation  of  the  project  research, 
facilitation  plans  and  workshops,  prototype  design  and  development,  and 
project  reporting.  All  are  listed  in  Appendix  A. 
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Corporate  Partners 

The  corporate  partners  in  the  project  were: 

♦  Audio  Visual  Sales  and  Service 

♦  Hewlett-Packard 

♦  Intergraph  Corporation 

♦  Image  Conversion  Systems 

♦  MediaServ 

♦  Microsoft  Corporation 

♦  Oracle  Corporation 

♦  Sybase  Inc. 

The  primary  corporate  partner  was  Intergraph  Corporation.  Intergraph 
provided  the  hardware  and  some  software  to  support  the  development  and 
use  of  the  prototype  both  at  CTG  and  at  the  Adirondack  Park  Agency. 
Intergraph  also  provided  significant  professional  services  in  the  design  and 
development  of  the  project  prototype.  Oracle,  Microsoft,  and  Sybase  each 
provided  a  range  of  software  products  to  support  the  prototype  efforts. 
Image  Conversion  Systems  provided  scanning  services  by  converting  a 
selected  set  of  paper  project  files  to  digital  form  with  the  necessary  indices 
for  use  in  the  prototype.  MediaServ  provided  consulting  during  the 
conceptual  phase  of  the  prototype  design  activities  and  Audio  Visual  Sales 
and  Service  provided  specialized  projection  equipment  in  support  of 
project  presentations. 


Project  workplan 


The  project  activities  were  conducted  between  Summer  1996  and  Spring 
1998.  A  detailed  chronological  list  of  project  and  information 
dissemination  activities  is  included  in  Appendix  D.  Three  interim  reports 
of  project  activities  and  results  were  submitted  to  NHPRC  at  six  month 
intervals.  These  reports  are  available  on  the  CTG  Web  site  at 
http://www.ctg.albany.edu/projects/er/ermn.html 
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Figure  I.  Models  for  Action  workplan  overview 
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As  illustrated  in  Figure  1,  Models  for  Action  integrated  and  built  upon  four 
existing  bodies  of  knowledge:  electronic  recordkeeping  theory  and 
practice,  archival  theory  and  practice,  business  process  improvement  and 
reengineering  methodologies,  and  system  development  methodologies. 

The  first  product.  Functional  Requirements  to  Ensure  the  Creation,  Maintenance, 
and  Preservation  of  Electronic  Records,  integrates  theoretical  and  practical  work 
in  the  areas  of  electronic  recordkeeping  and  archives.  This  product  was 
reviewed  and  evaluated  by  expert  practitioners  before  being  translated  into 
a  series  of  questions  or  cues  that  comprise  a  new  step  that  can  be 
incorporated  into  existing  BPI/BPR  methodologies  resulting  in  our  second 
product,  The  Records  Requirements  Analysis  and  Implementation  Tool  (REAIT). 
The  RRAIT  is  comprised  of  two  parts:  the  Records  Requirements 
EUcitation  Component  (RREC)  and  the  Records  Requirements 
Implementation  Component  (RRIC).  The  RREC  facilitates  the 
identification  of  records  management  requirements  during  business 
process  improvement  and  system  analysis  activities.  The  RRIC  focuses  on 
the  identification  of  management,  policy,  and  technology  strategies  that 
address  the  requirements  once  they  have  been  identified.  Combined,  these 
components  facilitate  the  identification  and  implementation  of  appUcation- 
specific  records  management  requirements.  Both  components  were  refined 
based  on  review  by  the  Project  Advisory  Committee. 

The  subsequent  activities  were  designed  to  test  the  RRAIT  in  the 
automation  of  a  record-intensive  business  process  at  the  New  York  State 
Adirondack  Park  Agency  (APA).  A  prototype  system  focused  on  APAs 
minor  project  review  process  was  designed  and  developed  incorporating 
technical  features  that  ensure  the  required  electronic  records  management 
functions  were  addressed.  Additionally,  supporting  management  and  pokey 
strategies  were  identified.  The  prototype  system  was  evaluated  in  terms  of 
agency  benefits  and  costs;  the  degree  to  which  the  original  set  of  electronic 
functional  requirements  was  addressed  in  the  prototype  system;  and  the 
degree  to  which  the  tools  met  the  criteria  for  generalheabkity  to  other 
organizations.  Experience  with  the  tools  and  the  prototype  in  this  real- 
world  setting  led  to  further  refinements  in  the  RRAIT. 


Models  for  Action  rests  on  four  bodies 
of  knowledge  -  records  management, 
archival  theory  &  practice,  business 
process  improvement,  and  system 
development  methods. 
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Chapter  2 


Tools  for  Identifying  and 
Implementing  Electronic 
Recordkeeping 
Requirements _ 


The  project  focused  on  the  development  of  practical  tools  to  support  the 
integration  of  electronic  records  management  considerations  into  business 
process  analysis  and  system  design  activities.  Two  products  were  developed 
over  the  course  of  the  project: 

♦  Functional  Reqxiirements  to  Ensure  the  Creation,  Maintenance, 
and  Preservation  of  Electronic  Records 

♦  Records  Requirements  Analysis  and  Implementation  Tool 
(RRAIl) 

These  products  were  tested  and  refined  in  the  development  of  technical 
specifications,  the  identification  of  associated  poHcy  and  management 
strategies,  and  the  creation  of  a  prototype  electronic  system  to  support  the 
land  use  permit  process  at  the  New  York  State  Adirondack  Park  Agency 
(APA).  This  chapter  describes  these  project  products.  Chapter  3  presents 
their  application  at  APA. 


Functional  Requirements  to  Ensure  the  Creation, 
Maintenance,  and  Preservation  of  Electronic  Records 


This  section  outlines  the  development,  content,  and  use  of  Vunctional 
Requirements  to  Ensure  the  Creation,  Maintenance,  and  Preservation  of  Electronic 
Records,  This  set  of  requirements  was  the  conceptual  keystone  for  much  of 
the  project  and  is  reflected  in  the  project’s  other  products.  The  Models  for 
Action  (MFA)  Functional  Requirements  were  developed  to  communicate  to 
program  and  information  technology  managers  what  standard 
organizations  must  achieve  to  ensure  that  electronic  records  are  created, 
maintained,  and  preserved  to  support  thek  operational,  informational,  and 
evidentiary  needs.  These  requirements  need  to  be  implemented  in  any 
system  developed  to  support  electronic  recordkeeping. 
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The  first  iteration  of  the  functional  Requirements  developed  in  the  spring 

and  summer  of  1996.  These  were  based  on  functional  Requirements  for 
Recordkeeping  developed  in  “^^ariables  in  the  Satisfaction  of  Archival 
Requirements  for  Electronic  Records  Management/’  a  research  project  of 
the  School  of  Library  and  Information  Sciences  at  the  University  of 
Pittsburgh  (Pittsburgh  Project).  They  were  also  informed  and  influenced 
by  “Preservation  of  the  Integrity  of  Electronic  Records,”  a  research  project 
of  the  University  of  British  Columbia;  the  US  Department  of  Defense 
Records  Management  Application  functional  Baseline  Requirements',  the  National 
Archives  and  Records  Administration’s  (NARA)  instructional  guide  for 
federal  Agencies  Records  Management  Requirements  for  Electronic  Recordkeeping, 
and  the  work  of  a  number  of  other  institutions. 

The  project  goal  was  to  develop  a  set  of  functional  requirements  for 
electronic  records  management  that  could  subsequently  be  translated  into 
questions  or  cues  to  identify  specific  requirements  related  to  a  business 
process.  Although  based  on  the  requirements  produced  in  the  Pittsburgh 
Project,  the  MFA  functional  Requirements  focus  on  the  systems  that  create 
records  rather  than  on  the  records  themselves.  Systems  were  defined  to 
encompass  poHcy  and  management  practices  as  well  as  technology 
components. 


Table  1.  Initial  Categories  of  Functional  Requirements 


1.  Record  Compliance  -  Legal  and  administrative  requirements  as 
well  as  best  practices  for  recordkeeping  related  to  a  specific 
business  process  are  addressed,  including  those  requirements 
specific  to  the  field  or  discipline  that  the  system  will  support. 

2.  System  Reliability  -  A  system  is  administered  in  line  with  best 
practices  in  the  information  resource  management  (IRM)  field  to 
ensure  the  reliability  of  the  records  it  produces. 

3.  Records  Capture  -  Records  are  created  or  captured  and  identified 
to  support  the  business  process  and  meet  all  recordkeeping 
requirements. 

4.  Records  Maintenance  -  Electronic  records  are  maintained  so  that 
they  are  accessible  and  retain  their  integrity  for  as  long  as  they  are 
needed. 

5.  Records  Useability  -  Electronic  records  are  usable  for  the  purposes 
for  which  they  were  created  and  can  be  exported  into  an  integral, 
accessible,  usable  format  from  the  creating  system  to  other  systems. 
This  includes  the  ability  to  transfer  the  records  to  an  archival 
repository  if  necessary. 


The  definition  of  a 
‘record’  used  in  the 
development  of  the  MFA 
functional  Requirements 
was,  “any  information 
received  in  the  normal 
course  of  business  and 
retained  as  evidence  of 
organization,  function, 
policies,  decisions, 
procedures,  operations  or 
other  activities,  or  because 
of  the  information 
contained  therein.”  This 
definition  was  a 
generahzed  version  of  the 
legal  definition  of  ‘record’ 
for  management  and 
archival  preservation 
found  in  New  York  State 
law  as  well  as  laws  in 
many  other  states. 

The  initial  MFA  functional 
Requirements  contained  five 
categories  as  shown  in 
Table  1. 
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Based  on  feedback  ftom  the  Advisory  Committee  and  a  group  of  national 
and  international  archival  and  records  management  experts,  the  Functwnal 
Requirements  were  refined.  In  addition,  two  significant  simplifications 
resulted  from  the  translation  of  the  Functional  Requirements  into  questions  or 
cues  designed  to  elicit  application- specific  records  management  issues — we 
redefined  ^record’  for  purposes  of  the  requirements  and  collapsed  the 
number  of  requirements  from  five  to  three: 

1.  Redefinition  of  ‘record.’  The  original  definition  was  judged  too 
vague  to  be  implementable  in  a  practical  tool  and  a  redefinition 
was  adopted  buHt  around  the  concept  of  a  business  transaction. 
Record’  was  redefined  as  “the  complete  set  of  documentation 
required  to  provide  evidence  of  a  business  transaction.” 

2.  Revised  Categories  of  Functional  Requirements.  The  five 
categories  of  requirements  were  collapsed  into  the  three  based  on 
the  following  rationale: 

•  It  became  clear  that  Compliance  is  not  an  independent 
requirement.  Rather,  it  is  an  attribute  achievable  through  the 
effective  identification,  implementation,  and  subsequent 
monitoring  of  the  specific  records  management  requirements 
associated  with  a  business  process. 

•  Parts  of  the  Records  Maintenance  requirement  were  already 
accounted  for  in  the  Records  Capture  requirement.  Therefore, 
redundant  requirements  were  eliminated  or  integrated  into 
Records  Capture.  The  remaining  requirements  of  Records 
Maintenance  were  combined  with  the  closely  related 
requirement.  Records  are  \J sable.,  to  create  a  new  requirement  - 
Records  Maintenance  and  Accessibility. 

The  revised  categories  of  functional  requirements  are  shown  in  Table  2  and 
described  more  fuUy  below 


Table  2.  Revised  Categories  of  Functional  Requirements 


1 .  Records  Capture  -  Records  are  created  or  captured  and  identified  to 
support  the  business  process  and  meet  all  recordkeeping 
requirements  related  to  the  process. 

2.  Records  Maintenance  and  Accessibility-  Electronic  records  are 
maintained  so  that  they  are  accessible  and  retain  their  integrity  for  as 
long  as  they  are  needed. 

3.  System  Reliability  -  A  system  is  administered  in  accordance  with 
best  practices  in  the  information  resource  management  (IRM)  field  to 
ensure  the  reliability  of  the  records  it  produces. 
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Underpinning  all  three  requirements  is  the  concept  of  ‘compliance/  The 
laws,  regulations,  and  policies  that  authori2e  or  define  a  specific 
government  business  process  will  either  explicitly  or  impKcidy  define  the 
recordkeeping  requirements  for  that  process.  These  requirements  identify 
what  records  must  be  created  and  may  define  requirements  for  records 
management,  access,  content,  and  structure.  In  addition,  many  professions 
or  disciplines  have  established  standards  or  best  practices  for  recordkeeping 
related  to  their  fields.  An  organi2ation  must  identify  these  requirements 
and  determine  how  they  will  be  implemented.  In  addition,  changes  in  the 
legal  and  regulatory  environment  and  in  professional  standards  need  to  be 
monitored  and  reflected  in  modifications  to  the  requirements.  Each 
requirement  can  be  mapped  to  a  compKance  factor  based  in  law,  regulation, 
standard,  or  best  practice.  The  use  of  the  term  ‘best  practice’  refers  to 
practices  formally  adopted  or  generally  accepted  by  a  profession  or 
discipline.  Examples  of  best  practices  include  Generally  Accepted 
Accounting  Principles  and  the  American  Health  Information  Association’s 
Recommended  Practices  for  Information  and  Documentation. 

This  set  of  three  requirements  has  proven  valuable  in  communicating 
electronic  records  management  concepts  and  issues  to  both  business  and 
IT  professionals.  Accordingly,  SARA  will  publish  them  as  part  of  a 
technical  leaflet  designed  for  state  and  local  government  officials  on 
defining  records  in  the  modern  information  technology  envkonment. 


The  Records  Requirements  Analysis  and  Implementation  Tool 

The  Records  Requirements  Analysis  and  Implementation  Tool  (RRAIl), 
summarized  in  Figure  2,  is  the  second  project  product.  The  tool  was 
developed  to  support  the  identification  of  records  management 
requirements  as  well  as  the  strategies  for  their  implementation.  The  RRAIT 
is  comprised  of  two  parts:  the  Records  Requirements  Elicitation  Component 
(RREC)  and  the  Records  Requirements  Implementation  Component  (RRIC).  The 
RREC  provides  a  framework  for  the  identification  of  records  management 
requirements  during  business  process  and  systems  analysis  stages  of 
information  system  design.  The  RRIC  focuses  on  the  identification  of 
management,  policy,  and  technology  strategies  for  implementing  the 
requirements  once  they  have  been  identified. 
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Figure  2.  Overview  of  the  RRAIT 
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The  Records  Requirements  Elicitation  Component  (RREC) 

The  purpose  of  the  Records  Requirements  Elicitation  Component  (RREC) 
is  to  translate  the  Functional  Requirements  into  a  set  of  questions  or  prompts 
that  assist  in  the  comprehensive  identification  of  application- specific 
records  management  requirements.  The  goal  is  to  seamlessly  integrate  the 
capture  of  these  requirements  into  activities  normally  conducted  during 
business  process  improvement  and  system  design.  The  RREC  is  divided 
into  three  components:  The  Business  Process  Level,  the  Record  Level,  and 
the  System  Level  which  map  back  to  the  three  categories  of  Functional 
Requirements^  as  shown  in  Figure  3. 


Figure  3.  Mapping  the  Functional 
Requirements  to  the  RREC 
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The  Business  Process  Level  focuses  on  those  records  management 
requirements  associated  with  the  business  process  that  is  to  be  automated. 
The  Record  Level  focuses  on  the  identification  of  records  management 
requirements  that  surround  the  record  after  it  has  been  generated  during 
the  course  of  a  business  transaction  or  process,  while  the  System  Level 
focuses  on  those  records  management  requirements  associated  with 
technology,  system  administration,  and  system  configuration  alternatives. 
Figures  4a-4c  provide  an  overview  of  the  three  levels  of  the  RREC  and 
records  management  issues  addressed  by  each. 


Business  Process  Level 


The  Business  Process  Level  of  the  RREC  was  developed  to  support  the 
identification  of  records  management  reqxiirements  associated  with  a  given 
business  process.  It  is  also  designed  to  distinguish  sub- tasks  and  records 
management  requirements  that  are  required  by  law,  regulation,  professional 
requirements,  or  organkational  policy  and  practices.  These  distinctions  are 
important  in  terms  of  justifying  requirements  and  determining  which,  if 
any,  sub-tasks  can  be  eliminated  or  modified. 

As  shown  in  Figure  4a,  this  level  of  the  RREC  seeks  information  at  the 
record  component  and  business  process  levels.  The  records  management 
requirements  gathered  at  this  level  are  focused  on  collecting  information 
about  the  process  itself,  and  the  modifications  to  records  at  points  in  the 
process,  in  terms  of  how  the  record  is  modified  (what  is  added,  deleted,  or 
changed)  and  who  should  have  authority  to  make  the  modifications.  It  also 
identifies  what  information  about  the  components  (such  as  individual 
documents,  associated  graphics,  or  signatures)  should  be  collected  and 
maintained. 

The  Business  Process  Level  questions  help  to  identify  required  information 
about  time  clocks  associated  with  the  process  to  ensure  that  information 
about  start  and  end  times  associated  with  a  given  task  are  captured  It  also 
calls  for  the  identification  of  other  information  or  documents  that  may 
need  to  be  accessed  and  consulted  but  perhaps  not  integrated  into  the 
record  so  that,  at  minimum,  the  system  will  allow  for  references  to  these 
sources.  This  section  of  the  RREC  also  captures  information  about  the 
types  of  documents  that  the  information  system  will  need  to  integrate  into 
the  record,  as  well  as  any  proofs  of  authenticity  such  as  original  signatures, 
notarizations,  or  electronic  time  stamps  that  must  be  captured  at  the 
document  or  record  component  level. 

The  Business  Process  level  section  of  the  RREC  also  supports  the 
identification  of  objects  (another  way  to  think  of  components  of  a  record) 
that  can  later  become  the  objects  in  an  object-oriented  database  structure. 
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This  section  also  gathers  the  required  meta  data  (information  about  the 
object  including  when  it  was  modified  and  by  whom)  for  each  of  the 
objects  or  components  of  a  record.  The  full  set  of  questions  from  the 
Business  Process  Level  of  the  RREC  can  be  foixnd  in  Appendix  E. 


Figure  4a.  Business  Process  Level  of  the  RREC 
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Business  Process  Level  -  for  each  sub-task 
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3.  When  is  the  record  get  modified? 

4.  What  components  of  the  record  are  created  or  modified? 

5.  Information  about  the  record  components 

6.  Proofs  of  authenticity  associated  with  the  component 


The  Business  Process  Level  section  of  the  EHEC  was  implemented  very 
successfully  in  the  context  of  a  business  process  improvement  activity. 
There  are  a  number  of  ways  that  the  background  information  can  be 
gathered  to  support  the  business  process  improvement  activity.  For 
example,  interviews,  surveys,  and  focus  groups  could  be  conducted  to 
gather  preliminary  information. 


Record  Level 


As  shown  in  Figure  4b,  the  primary  unit  of  analysis  for  the  Record  Level  of 
the  RREC  is  the  record  itself  In  general  terms,  this  section  of  the  tool 
seeks  to  capture  records  management  requirements  associated  with  access 
and  use  over  time,  for  both  the  record  in  aggregate  and  its  component 
parts.  The  questions  are  focused  on  capturing  records  management 
requirements  related  to  the  access  and  maintenance  of  records  once  they 
have  been  created  or  after  a  business  transaction  has  been  completed. 
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This  section  of  the  RREC  also  identifies  the  specific  components  of  the 
record  that  must  be  retrievable  and  reproducible  for  use  by  both  internal 
and  external  secondary  users.  It  also  focuses  on  the  identification  of  an 
organkation’s  records  disposition  plan,  including  the  individual(s) 
responsible  for  disposing  of  records  according  to  the  plan  and  those 
responsible  for  modifying  or  updating  the  plan.  The  full  set  of  questions 
for  the  Record  Level  of  the  RREC  are  shown  in  Appendix  E. 


Figure  4b.  Record  Level  of  the  RREC 
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1 .  What  is  a  ‘record’? 

2.  What  is  a  legal  minimum  record? 

3.  Required  record  structure 

4.  information  about  the  record 

5.  information  to  verify  authenticity  and  interpretation 

6.  Interna!  access  mechanisms 

7.  External  access  mechanisms 

8.  Reproducing  records  for  external  dissemination 

9.  Records  disposition  plans _ 


The  Record  Level  specifies  the  information  that  needs  to  be  collected  in 
attempting  to  identify  a  comprehensive  set  of  records  management 
requirements,  but  it  does  not  dictate  the  mechanisms  by  which  the 
questions  are  asked  and  answered.  Several  methods  can  be  useful.  For 
example,  the  answers  could  be  acquired  through  interviews  of  relevant 
staff,  conversations  with  experts  such  as  the  legal  staff,  group  decision 
conferences,  or  surveys.  The  method  used  to  answer  the  questions  outlined 
in  the  Record  Level  of  the  RREC  should  be  determined  in  much  the  same 
way  a  research  method  would  be  selected  to  answer  a  research  question.  A 
variety  of  factors  need  to  be  considered  and  the  most  cost-effective 
mechanism  for  gathering  the  information  should  be  used. 


System  Level 


The  System  Level  of  the  RREC  is  more  directly  related  to  technology  than 
the  other  sections.  As  shown  in  Figure  4c,  the  questions  at  this  level  are 
focused  on  how  a  system  will  support  the  integration  of  the  information 
and  documents  (record  components)  identified  at  the  Business  Process  and 
Record  Levels.  In  other  words,  the  Business  Process  Level  questions 
facilitate  the  identification  of  what  information  and  documents  must  be 
integrated  into  a  record,  the  Record  Level  focuses  on  how  the  record  and 
its  components  will  be  maintained  and  accessed  over  time,  and  the  System 
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Level  focuses  on  how,  from  a  technical  standpoint,  the  information  system 
will  accommodate  the  integration  of  and  ongoing  access  to  record 
components.  This  section  also  poses  questions  about  future  system 
migrations,  focusing  on  the  types  of  hardware  and  software  platforms  that 
the  system  may  be  migrated  to  over  time.  These  questions  prompt  the  user 
to  consider  the  feasibility  of  alternative  migration  plans  which  may  have  an 
effect  on  current  technology  choices. 


Figure  4  c.  System  Level  of  the  RREC 
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The  System  Level  questions  also  seek  to  capture  meta  data,  industry 
standards,  and  jurisdictional  requirements  associated  with  specific 
technology.  For  example,  technologies  such  as  digital  imaging,  GIS,  and 
EDI  may  require  different  types  of  meta  data  and  may  reqioire  that  certain 
standards  are  met  within  a  given  state  or  nation,  or  these  standards  may  be 
tied  to  commonly  accepted  industry  standards.  Additionally,  industry, 
organi2ational,  or  professional  standards  for  system  administration,  back¬ 
up,  and  disaster  recovery  are  identified  through  this  section  of  the  RREC. 


Records  Requirements  Implementation  Component  (RRIC) 

The  Records  Requirements  Implementation  Component  (RRIC)  focuses 
on  the  identification  of  strategies  or  mechanisms  that  can  be  used  to 
address  the  full  set  of  records  management  requitements  identified  through 
the  Business  Process,  Record,  and  System  Levels  of  the  RREC. 

As  shown  in  Figure  5,  the  RRIC  focuses  on  the  identification  of 
technology,  management,  and  policy  strategies  to  address  the  requirements 
identified  through  the  Business  Process,  Record,  and  System  Levels  of  the 
RREC. 
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The  RRIC  (see  Appendix  E)  provides  an  organizing  framework  for  records 
management  requirements  and  strategies  for  addressing  them.  In  some 
cases,  the  same  technology,  management,  or  policy  strategies  may  address  a 
range  of  records  management  requirements.  In  other  cases,  specific 
strategies  may  be  necessary  to  ensure  that  the  individual  requirements  are 
met.  For  example,  one  requirement  might  state  that  the  record  of  a 

Figure  5.  Implementation  Component 
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For  each  of  the  identified  RM  Requirements: 

Can  it  be  addressed  through  technology? 

If  yes... 

a.  will  policies  need  to  be  developed  or  changed? 

b.  what  sorts  of  management  practices  will  be 
required? 

If  no... 

c.  what  policies  and  management  strategies  will 
support  the  requirements? 


completed  transaction  should  be  moved  into  an  archival  vault  at  which 
point  no  further  modifications  can  made  to  the  record.  This  requkement 
may  be  supported  by  technology  through  the  use  of  workflow  features 
which  would  move  the  record  into  another  location  after  the  final  step  in 
the  process  has  been  completed.  However,  policies  must  be  created  that 
state  clearly  what  the  components  of  a  ‘final  record’  should  be  and  when  a 
record  is  deemed  ‘final.’  Further,  management  practices  must  be  put  in 
place  to  govern  who  is  authorized  to  move  the  record  into  the  vault  and 
what  components  of  the  record  must  be  maintained  in  the  archive.  Once 
the  management  and  policy  strategies  have  been  determined,  technology 
can  be  used  to  allow  only  the  person  authorized  to  archive  a  record  the 
technical  permission  or  capability  to  do  so.  The  technology  can  also  be 
used  to  provide  an  audit  trail  to  ensure  that  only  that  individual,  at  the  right 
time,  has  archived  the  record.  Another  policy  that  would  support  this 
requirement  would  be  a  prohibition  against  sharing  user  IDs  and  passwords 
among  the  system  users. 
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Figure  6  completes  the  conceptual  overview  of  the  RRAIT  by  combining 
the  levels  and  components  into  an  integrated  picture  of  the  tool  and  its 
various  areas  of  emphasis. 
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Chapter  3.  Testing  the  Tools  at  the 

Adirondack  Park  Agency 


This  chapter  presents  the  activities  undertaken  with  the  Adirondack  Park 
Agency  to  test  the  practicaKty  of  the  tools  in  supporting  the  development 
of  an  electronic  system  that  addresses  electronic  records  requirements  as 
part  of  the  permitting  process. 


Records  management  issues  at  APA 

In  its  capacity  as  regulator  of  development  and  subdivision  in  the  6  million 
acre  Adirondack  Park,  APA  serves  a  varied  clientele.  Owners  of  land 
within  the  Park  seek  advice  on  whether  a  permit  is  necessary  for  proposed 
development  projects  or  as  a  condition  of  mortgage  financing  and  similar 
real  property  transactions.  APA  issues  permits  after  determining  that  the 
proposed  development  satisfies  statutory  and  regulatory  requirements.  In 
issuing  a  permit,  the  Agency  is  required  to  consider  37  statutorily 
enumerated  development  considerations.  Permits  are  recorded  in  County 
Clerks’  offices,  and  'run  with  the  land’  very  similar  to  a  deed,  binding 
subsequent  purchasers  and  other  grantees  of  the  land  involved.  Each 
permit  contains  extensive  and  detailed  findings  about  the  proposed  project; 
the  envkonmental  setting  including  the  land  use  area  in  which  the 
development  is  to  take  place;  the  proximity  of  the  project  to  navigable 
waters,  wetlands,  historic  preservation  areas  and  endangered  species 
habitats;  and  the  impact  the  proposed  development  will  have  on  the  Park’s 
environment.  Permits  indicate  the  conditions  under  which  adverse  impact 
on  Park  resources  can  be  minimized.  In  addition,  input  from  owners  of 
property  adjoining  a  proposed  development  site  is  weighed.  The  agency 
also  issues  formal  legally  binding  'letters  of  non-jurisdiction’  when  it 
determines  that  no  permit  is  required  for  a  proposed  project. 

In  accordance  with  the  Agency’s  regulations,  information  about  any  prior 
Agency  actions  associated  with  a  project  parcel  must  be  reviewed  in 
decisions  about  the  issuance  of  land  use  permits  for  new  development 
projects.  Since  1973,  the  Agency  has  reviewed  over  12,000  development 
projects  and  subdivisions,  averaging  over  350  permits  issued  each  year. 
These  records  alone  total  over  150,000  pages  including  6,000  large  format 
maps  in  separate  locations.  In  addition,  APA  maintains  a  variety  of  other 
records  related  to  real  property  including  reported  violations  of  the  three 
environmental  laws  administered  by  the  Agency.  About  1,000  multi-page 
letters  constituting  binding  legal  advice  about  whether  a  permit  is  necessary 
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are  also  issued  annually.  These  and  other  land  management  documents, 
including  legal  opinions,  jurisdictional  advice,  vested  rights  decisions, 
electronic  and  paper  maps,  photographs  and  other  non-standard 
documents,  dating  from  1973  to  the  present,  are  used  in  decision  making 
about  new  land  use  development  in  the  Adirondack  Park. 

This  array  of  information  is  stored  in  file  cabinets,  map  trays,  microfiche 
jackets,  film  canisters,  boxes,  closets,  stairwells,  and  any  other  available 
space  in  the  Agency’s  16,000  square  foot  office.  Access  to  these  records 
has  been  limited  to  the  Ray  Brook  headquarters  and  is  confounded  by  a 
lack  of  personnel  to  manage  extensive  paper  files  along  with  various  special 
media  and  formats.  At  the  same  time,  however,  the  Agency  has  developed 
an  extensive  capability  using  geographic  information  system  technologies.  It 
has  created  or  enhanced  automated  maps  to  describe  the  extent  and 
characteristics  of  land  use  areas  depicted  on  the  Official  Adirondack  Park 
Land  Use  and  Development  Plan  Map  and  to  prompt  key  environmental 
issues  for  permit  review  staff 

The  Agency’s  goal  in  participating  in  the  project  and  more  generally  in 
learning  about  alternative  options  for  the  development  of  an  electronic 
land  use  permit  system,  were  focused  on  improving  service  to  customers 
through  the  use  of  information  technology.  More  specifically,  APA  was 
interested  in  improving  the  land  use  permit  process  and  increasing  access  to 
records  in  order  to: 

♦  Reduce  transaction  turnaround  time 

♦  Increase  staff  productivity 

♦  Demonstrate  predictability  and  consistency  in  its  land-use  decisions 


Testing  the  RRAIT  with  APA 

The  project  tools  were  tested  in  the  context  of  improving  the  Agency’s 
minor  project  review  process.  A  number  of  techniques  were  used  to 
capture  the  records  requirements  including  interviews,  surveys,  and  group 
decision  conferences. 


Capturing  records  requirements  with  the  Business  Process  Levei  of  the  RREC 

The  Business  Process  level  of  the  RREC  was  used  in  business  process 
improvement  (BPI)  activities  with  APA.  The  BPI  activities  served  multiple 
purposes:  to  create  a  consistent  view  of  the  process  shared  by  all  its 
participants,  to  identify  modifications  to  the  process  that  would  increase 
staff  productivity  and  improve  customer  service,  to  identify  the  records 
management  requirements  associated  with  the  process,  and  to  define  the 
workflow  to  be  embedded  inThe  prototype  system  described  below. 
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A  number  of  preliminary  activities  were  conducted  prior  to  the  two-day 
BPI  activity  with  APA.  First,  interviews  were  conducted  with 
approximately  15  staff  members.  The  purpose  of  the  interviews  was  to 
identify  issues  associated  with  the  process  from  the  perspective  of  the  staff 
involved  in  it.  The  interviews  also  elicited  issues  associated  with  access  to 
agency  records.  A  preliminary  process  model  was  then  developed  and  used 
as  a  starting  point  for  the  BPI  activity.  This  model  documented  the  current 
minor  project  review  process  and  identified  issues  associated  with  access  to 
records  as  part  of  the  process.  Subsequently,  a  business  process 
improvement  activity  was  conducted,  using  the  Business  Process  Level  of 
the  RREC.  (A  brief  description  of  the  steps  involved  in  the  use  of  the 
Business  Process  Level  of  the  RREC  is  provided  in  Appendix  E.)  The 
improved  process  and  the  preliminary  set  of  associated  records 
management  requirements  became  the  foundation  for  automating  the 
review  process  and  for  identifying  the  management  and  policy  strategies 
that  would  support  it.  This  activity  demonstrated  that  the  Business  Level 
of  the  RREC: 

♦  could  be  seamlessly  integrated  into  business  process  improvement 
activities 

♦  aided  in  the  identification  of  sub-tasks  that  could  be  eliminated  or 
moved  to  other  parts  of  the  process 

♦  prompted  the  participants  to  identify  a  comprehensive  set  of  records 
management  requirements  associated  with  the  business  process 

♦  facilitated  the  identification  of  management  and  policy  issues  that 
need  to  be  addressed  in  support  of  a  full  system  implementation 


Capturing  records  requirements  with  the  Record  Level  of  the  RREC 

A  staff  survey  was  used  to  gather  information  specified  in  the  Record  Level 
of  the  RREC.  The  questions  focused  primarily  on  internal  secondary  use 
of  project  records  and  identified  the  types  of  documents  or  components 
of  a  record  that  individual  staff  members  require,  as  well  as  theic  preferred 
mode  of  access.  The  survey  asked  which  other  agency  business  processes 
or  purposes  might  require  access  to  the  project  record,  and,  for  each 
process  or  purpose,  which  components  of  the  record  need  to  be  accessed 
and  what  are  the  most  efficient  and  effective  ways  of  gaining  access  (e.g.,  by 
project  number,  land  owner’s  name,  project  type,  staff  member  assigned). 
The  identified  document  types  and  access  indexes  became  the  foundation 
for  an  object-oriented  database  which  was  used  in  the  prototype. 

Other  activities  associated  with  the  Record  Level  included  a  review  of 
additional  potential  modifications  to  the  minor  project  review  process, 
confirmation  of  the  requited  components  of  a  record  of  a  minor  permit 
transaction,  and  information  about  each  of  the  record  components  and  the 
record  itself  requited  to  support  access  and  usability  over  time. 
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The  process  of  testing  the  Record  Level  section  of  the  RREC  showed  that 
the  questions  were,  for  the  most  part,  easily  understood  and  answerable  by 
APA  staff  For  some  questions,  such  as  the  identification  of  a  legal 
minimum  record,  the  staff  decided  that  additional  work  would  be  required 
to  develop  final  recommendations.  In  other  cases,  the  answers  were  easily 
acquired  and  translated  into  records  management  requirements  for  a  full 
system  implementation. 

Capturing  records  requirements  with  the  System  Levei  of  the  RREC 

The  System  Level  of  the  RREC  is  focused  on  how  a  new  system  will 
support  the  integration  of  information  and  documents  identified  in  the 
Business  Process  Level.  In  other  words,  the  Business  Process  Level 
questions  facilitate  the  identification  of  information  and  documents 
must  be  integrated  into  a  record,  while  the  System  Level  section  focuses  on 
ho7P,  from  a  technical  standpoint,  the  information  system  will  accommodate 
the  integration. 

After  specifying  the  different  types  of  documents  that  must  be  integrated 
into  a  record  of  a  minor  permit  transaction,  technology  options  to  support 
this  integration  were  identified.  Digital  imaging  of  all  documents  submitted 
to  the  Agency  from  applicants  and  other  external  parties  was  selected  to 
accommodate  a  number  of  different  types  of  documents.  The  Agency’s 
recent  acquisition  of  a  large  format  scanner  will  accommodate  the 
digitization  of  E-size  maps  and  a  multi-page  scanner  was  acquired  to 
support  the  digitization  of  smaller  documents.  Agency  documents 
generated  in  electronic  form  would  be  included  in  the  record.  Scanning 
those  documents  that  have  associated  proofs  of  authenticity  such  as 
original  signatures  and  notarization,  was  chosen  as  the  most  effective 
mechanism  for  maintaining  a  legal  record  of  the  transaction.  Integrating 
the  prototype  with  the  existing  GIS  system  was  selected  as  the  way  to 
ensure  that  necessary  maps  and  related  information  are  maintained  as  part 
of  a  record.  AU  of  the  documentation  for  a  project  record  can  be  linked 
through  the  document  management  capabilities  of  the  products  used  in  the 
development  of  the  prototype. 

Conceptually,  all  of  the  project  documents  maintained  within  the  system 
can  be  linked  in  a  project  record  through  the  object-oriented  data  model. 
For  those  documents,  such  as  satellite  photographs,  which  cannot 
physically  be  included  as  components  in  a  project  record,  the  inclusion  of 
index  and  location  information  was  deemed  sufficient. 

In  order  to  minimize  effort  in  terms  of  future  migration,  a  tool  that 
supports  the  viewing  of  documents  created  in  over  70  different  formats 
across  a  variety  of  software  packages  was  selected  to  support  the  prototype. 
This  capability  decreases  the  number  of  different  packages  for  which 
migration  concerns  will  be  an  issue. 
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A  review  of  technology  policies  and  standards,  including  those  developed 
by  the  NYS  Office  for  Technology,  was  conducted  by  CTG  and  SARA 
staff  and  provided  to  the  Agency  for  consideration  in  a  full  system 
implementation. 

Testing  the  RRIC  at  APA 

A  number  of  policy  and  management  issues  emerged  during  the  records 
requirements  elicitation  phase.  Some  could  be  addressed  by  technology  but 
others  required  management  decisions  or  agencywide  policies  for  their 
resolution. 

For  example,  APA  needs  to  establish  a  definition  of  a  minimum  legal 
record  for  a  project  transaction.  A  related  issue,  identified  during  the  cost- 
performance  workshop,  had  to  do  with  the  contents  of  a  completed  project 
review  record.  At  present,  when  a  project  review  is  completed,  all  materials, 
regardless  of  long-term  value  are  retained  in  the  file.  This  includes  material 
such  as  telephone  messages,  informal  notes,  and  draft  documents  that  may 
have  been  valuable  during  the  work  process  but  have  very  limited  or  no 
continuing  value  to  the  agency.  When  freedom  of  information  law  (FOIL) 
requests  are  received,  the  FOIL  officer  must  review  each  document  in  a 
record  and  physically  separate  those  that  are  releasable  from  those  that  are 
not  In  addition,  she  must  provide  the  requester  with  a  Kst  of  non- 
releasable  documents  in  the  file.  This  is  invariably  a  cumbersome  and  time- 
consuming  process  that  could  be  minimized  by  an  agencywide  policy 
stating  what  should  be  maintained  in  a  record  after  a  transaction  has  been 
completed  and  defining  the  standard  components  of  that  record  that  are 
not  releasable  under  FOIL. 

The  RRIC  helps  identify  and  evaluate  technology,  management,  and  policy 
strategies  to  support  the  implementation  of  records  management 
requirements.  In  many  cases,  technology  can  be  used  to  support  records 
management  requirements,  but  the  costs  of  implementing  these  technology 
strategies  may  be  very  expensive  or  not  cost-effective  in  terms  of  overall 
system  or  business  goals.  Therefore,  the  RRIC  assists  organizations  in 
analyzing  the  cost-effectiveness  of  technology  strategies  versus 
management  and  poKcy  strategies  in  addressing  records  management 
requirements. 

A  number  of  technology  options  were  identified  over  the  course  of  the 
project  that  would  support  the  records  management  requirements  of  APAs 
minor  project  review  process.  Workflow  and  document  management  were 
identified  as  key  technologies  to  support  records  management 
requirements.  These  technologies  range  from  very  complex  systems  that 
require  substantial  customization  in  order  take  full  advantage  of  their 
capabilities  to  more  simple  off-the-shelf  packages  that  rely  less  on 
customization  and  more  on  human  processes  and  procedures.  For 
example,  the  Business  Process  Level  of  the  RREC  identified  who  should 
be  able  to  change  a  project  record  at  various  stages  of  the  project  review 
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process.  These  requirements  could  be  addressed  through  the  use  of 
workflow  software  and  the  development  of  rides  within  the  system  that 
allow  or  deny  access  to  the  record  or  its  individual  components.  The 
development  of  the  rules  within  the  workflow  system  would  require 
substantial  customization  and  therefore  substantially  more  development 
time.  Alternatively,  the  Agency  could  establish  a  set  of  policies  or 
procedures  that  do  not  rely  on  technology  for  their  implementation. 

In  order  to  estimate  the  relative  costs  and  benefits  of  technology  strategies 
to  support  records  management  requirements,  a  two-day  cost-performance 
modeling  conference  was  conducted  with  APA  staff  in  April  1998.  The 
workshop  was  designed  to  evaluate  the  potential  costs  and  benefits  of 
various  levels  of  a  fully  implemented  system,  based  on  experience  with  the 
prototype.  In  particular,  it  sought  to  identify  benefits  in  terms  of  reducing 
transaction  turnaround  time  (faster),  quality  improvements  (fetter),  and 
decreases  in  cost  per  transaction  (cheaper)  that  would  result  from  various 
levels  of  full  system  implementation.  While  the  benefits  of  system 
implementation  would  accrue  to  other  work  processes  in  the  Agency,  the 
primary  focus  of  the  workshop  was  on  the  Agency’s  minor  project  review 
process.  The  workshop  activities  both  applied  the  REJC  and  affirmed  its 
usefulness  in  terms  of  its  ability  to  focus  on  the  management  and  policy 
strategies  required  to  support  full  system  implementation. 

The  workshop  activities  produced: 

♦  estimates  for  minor  project  review  processing  times  (elapsed  time 
and  time  on  task) 

♦  three  alternative  levels  of  full  system  implementation 

♦  cost  estimates  for  the  three  levels  of  system  implementation 

♦  estimates  of  potential  benefits  in  terms  of  cost  savings,  quakty 
improvements,  and  decreases  in  transaction  turnaround  time  for 
each  level 

Based  on  the  analysis  conducted  during  the  workshop,  the  sophisticated 
workflow  component  of  the  prototype  did  not  appear  to  offer  sufficient 
marginal  benefit  over  marginal  costs  from  the  perspective  of  the 
participants.  Under  this  scenario,  the  records  management  issues  that 
would  have  been  addressed  through  the  workflow  capabilities  would 
therefore  have  to  be  addressed  through  management  and  policy  strategies. 
This  limited  analysis  provided  an  example  for  the  Agency  to  use  in  future 
decision  making  about  full  system  implementation  and  it  provided  a  useful 
framework  for  making  choices  among  technology  strategies,  and 
management  and  policy  options  for  meeting  records  management 
requirements. 
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A  prototype  system  to  support  the  minor  project  review 
process  at  APA 


A  prototype  system  to  support  APA’s  minor  project  review  process  was 
based  on  information  gathered  from  the  interviews,  business  process 
improvement  activities,  and  the  use  of  the  REAIT.  It  was  designed  to  help 
APA  staff  determine  which  features  and  functionality  of  a  fully 
implemented  system  would  best  support  the  Agency’s  productivity  and 
customer  service  goals.  The  prototype  also  served  as  a  mechanism  for 
identifying  management  and  policy  strategies  that  would  need  to  be 
developed  to  complement  the  system  implementation.  The  following 
technology  components  were  used  in  the  development  of  the  prototype 
system: 

♦  Document  management 

♦  Geographic  information  system 

♦  Workflow 

♦  Database 

♦  User  interface 

♦  Networking  and  communications  technology 


The  prototype  is  a  network-based  integrated  document  management  and 
workflow  system  capable  of  supporting  a  fully  electronic  record  of  the 
minor  project  review  process.  It  is  also  capable  of  accessing,  analy2ing,  and 
capturing  information  from  the  Agency’s  geographic  information  system 
(GIS)  and  archiving  the  project  record.  The  prototype  functionality 
includes: 

♦  Document  imaging  and  document  management 

♦  User-friendly  data  entry  screens 

♦  Assignment  of  project  staff 

♦  Routing  of  work  to  appropriate  staff 

♦  User-friendly  search  capabilities 

♦  Automatic  forms  generation 

♦  Access  to  the  Agency’s  GIS 

♦  Archiving  of  project  records 


Models  for  Action 


Page  41 


The  improved  APA  project  review  process 

A  high-level  diagram  of  the  improved  project  review  process  that  resulted 
from  the  BPI  work  and  the  use  of  the  RREC  is  shown  in  Figure  7.  It 
represents  a  number  of  changes  from  the  current  process,  some  enabled  by 
technology  and  others  representing  changes  to  the  process  itself  or  changes 
in  the  manner  or  order  in  which  the  sub-tasks  of  the  process  are 
completed.  An  example  of  a  technology-enabled  change  is  the  parallel 
processing  made  possible  by  simultaneous  access  to  digital  project  records. 
As  can  be  seen  from  the  figure,  projects  often  require  consultations  from 
natural  resource  staff,  such  as  soil  scientists  or  wetlands  biologists,  as  well 
as  legal  consultation.  Under  the  current  paper  process,  the  review  and 
analysis  must  be  conducted  sequentially  as  there  is  only  one  copy  of  the 
project  file.  This  technology- enabled  change  would  allow  these  reviews  to 
take  place  concurrently  Technology  could  also  improve  project-related 
correspondence.  For  example,  standard  language  for  permits  and 
additional  information  requests  could  be  automatically  inserted  in  these 
documents  as  they  are  prepared  for  specific  project  applications,  thus 
saving  staff  time  and  assuring  consistency  across  projects.  Other  types  of 
correspondence,  currently  generated  on  paper  or  in  electronic  form,  are 
passed  among  staff  for  review  in  either  hardcopy  or  by  an  exchange  of 
disks.  A  networked  system  would  improve  performance  by  eliminating  the 
use  of  ‘sneaker  net’  in  the  sharing  and  review  of  Agency  correspondence. 

Process-related  records  management  requirements 

The  use  of  the  Business  Process  Level  of  the  RREC  led  to  the 
identification  of  the  records  management  requirements  within  the  project 
review  process  at  the  sub-task  level.  During  the  initial  business  process 
improvement  activity,  five  sub-tasks  were  identified: 

♦  Acceptance  of  application 

♦  Completeness  review 

♦  Proj  ect  review  proces  s 

♦  Permit  approval 

♦  Archiving 


The  Acceptance  of  Application  sub-task  includes  initial  receipt  and  cursory 
review  of  an  application,  assignment  of  staff  including  the  Project  Review 
Officer  (PRO)  and  any  required  natural  resource  or  legal  staff,  and 
forwarding  the  electronic  application  folder  to  the  appropriate  staff.  A 
diversity  of  documentation  is  integrated  into  the  project  file  during  this 
sub-task  such  as  the  application,  a  site  plan  map,  deeds,  tax  maps,  and 
information  about  prior  Agency  actions  on  the  project  property.  During 
the  initial  review,  paper  maps  or  digital  spatial  data  is  also  accessed  in-house 
and  integrated  into  the  record.  An  electronic  system  must  therefore 
accommodate  or  reference  the  location  of  the  project  documents  and  other 
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Figure  7.  The  improved  APA  project  review  process 
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Each  sub-task 
of  the  minor 
project  review 
process  adds  to 
or  modifies  the 
record  of  the 
transaction. 


information  sources  used  to  support  this  sub- task.  In  addition,  the  receipt 
of  an  application  starts  a  15-day  statutory  clock.  Information  about  the 
receipt  date  and  the  number  of  elapsed  days  since  receipt  is  a  critical 
activity  required  by  state  law.  A  number  of  authenticity  requirements  are 
important.  For  example,  the  original  signature  on  the  permit  application  is 
required  by  law,  the  date  stamp  on  the  application  is  required  by  regulation. 
Therefore,  an  electronic  system  must  maintain  proofs  of  authenticity.  At 
this  initial  point  in  the  process,  only  two  individuals,  the  Director  of 
Regulatory  Programs  (DRP),  and  the  Secretary,  are  authorized  by  Agency 
practice  to  change  the  project  record. 

Under  the  revised  technology- supported  process,  the  Completeness  ^view 
sub-task  begins  when  an  assigned  PRO  receives  the  project  file.  The  file  is 
simultaneously  available  to  legal  and  natural  resource  staff  The  level  of 
involvement  of  these  staff  may  vary  from  simple  notification  that  the 
project  has  been  started  to  specific  issues  that  need  to  be  addressed  in  the 
project  review.  Information  related  to  the  37  statutory  development 
considerations  must  be  accessed  during  this  sub-task  and  items  such  as 
additional  paper  maps,  GIS  data,  deeds,  narratives  of  map  analyses, 
property  history  notes,  and  engineering  reports  are  integrated  into  the 
record.  Site  visits  are  conducted  during  this  sub-task  and  therefore  site  visit 
notes,  soil  analysis  results,  visual  analysis  reports,  and  narrative  about  the 
potential  impacts  on  other  affected  landowners  is  integrated  into  the  record 
during  the  completeness  review  If  an  Additional  Information  Request 
(AIR)  is  issued,  this  document  is  also  integrated  into  the  record.  Under  the 
current  system  the  DRP,  PRO,  and  Secretary  are  authorized  to  make 
changes  during  this  phase.  Under  the  modified  process,  legal  and  natural 
resource  staff  would  also  have  authorization  to  add  comments  or 
documentation  to  the  record  or  documents  within  it.  Since  this  sub-task 
must  be  completed  within  15  days  of  the  receipt  of  the  application,  the 
timeclock  must  be  updated.  If  the  application  is  deemed  incomplete,  and 
an  AIR  is  issued,  the  statutory  timeclock  is  stopped  until  such  time  as  the 
additional  required  information  is  received  from  the  applicant.  The  AIR 
has  authenticity  requirements  such  as  original  signatures  and  an  executed 
Notice  of  Complete  Application  once  a  project  application  has  been 
deemed  complete.  It  is  also  Agency  practice  to  maintain  a  copy  of  the 
certified  mail  receipt  from  the  AIR  mailing. 

During  the  Project  'Review  sub-task,  the  components  added  to  a  record 
include  memos  reporting  consultations  with  staff  from  APA  and  other 
agencies  such  as  the  NYS  Department  of  Environmental  Conservation 
(DEC),  notes  from  meetings  with  the  applicant,  confidentiality  requests, 
and  determinations  of  trade  secret  status.  The  project  review  process 
must  be  completed  within  45  days  of  the  date  that  the  application  was 
deemed  complete  for  minor  projects.  Therefore,  timeclock  information 
must  be  maintained.  Under  the  current  process  only  the  PRO  and  the 
Secretary  are  authorized  to  change  the  record  during  this  sub-task,  but  in 
the  improved  process  legal  and  natural  resource  staff  would  also  be  able  to 
modify  certain  elements  of  the  record  during  their  concurrent  review.  No 
authentication  requirements  were  identified  for  this  sub-task. 
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The  Vermit  Approval  sub-task  results  in  either  the  issuance  of  a  permit  or  a 
referral  to  the  Agency  Board  for  a  public  hearing.  In  the  case  where  the  permit 
is  approved  by  APA  staff,  the  record  will  include  drafts  of  the  permit,  results 
of  public  comment,  comments  on  permit  drafts,  a  copy  of  the  approved  plan, 
the  final  issued  permit,  a  reference  to  any  oversi2ed  map  (those  that  are  too 
large  to  be  included  in  a  paper  project  file),  and  a  transmittal  letter  to  the 
appKcant.  In  addition,  the  permit  must  be  filed  with  the  County  Clerk’s  office. 
Once  this  is  done,  a  stamped  card  is  received  by  the  Agency  from  the  County 
Clerk  and  is  also  integrated  into  the  project  record.  Proofs  of  authenticity 
include  an  original  signature  and  notarrzation  on  the  permit,  the  stamped  card 
firom  the  County  Clerk’s  office,  and  a  certified  mail  receipt.  The  issuance  of  a 
permit  stops  the  regulatory  review  clock  for  the  project  and  information  about 
the  end  date  must  be  included  in  the  record.  During  this  sub-task,  the  PRO, 
DRP,  Executive  Director,  and  Secretary  are  authorized  to  change  the  record. 

If  APA  staff  do  not  approve  the  project,  a  request  for  public  hearing 
before  the  Agency  Board  is  drafted  and  included  in  the  project  file. 
Additional  memos  from  consultations  may  be  added  to  the  project  file. 

The  Board  will  issue  either  a  denial  order  or  a  permit,  and  one  or  the  other 
is  added  to  the  project  record.  If  the  project  does  go  to  public  hearing. 
Agency  Board  minutes  wiU  also  be  included  in  the  project  record. 
Authentication  requirements  include  an  original  signature  on  either  the 
permit  or  the  denial  order.  If  a  permit  is  issued,  the  other  documentation 
noted  above  is  also  included  in  the  record. 

The  modified  process  reflects  a  new  sub-task  in  the  process  iot  Archiving  a 
completed  project  record.  This  step  involves  the  purging  of  documents  in 
a  project  record  that  are  not  required  for  long-term  access.  Ideally,  the 
project  record  would  be  reduced  to  the  level  of  a  minimum  record  in  terms 
of  legal  and  evidentiary  requirements  and  secondary  uses.  Modifications  to 
the  record  during  this  sub-task  are  made  only  by  the  archivist  or  the  DRP. 


Prototype  components 


The  following  section  discusses  the  components  of  the  prototype  system 
and  ties  these  components  to  the  records  management  requirements 
described  above. 


Document  imaging  and  document  management 

The  prototype  supports  the  scanning  of  all  documents  that  are  submitted 
to  the  Agency  in  application  for  a  permit.  The  imaging  component  of  the 
prototype  supports  the  records  capture  requirements  associated  with  the 
project  review  process,  while  the  document  management  functionaKty 
supports  many  of  the  records  access  requirements.  Additionally,  document 
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Figure  8.  Screen  showing 
documents  in  a  record 


imaging  was  used  to  capture  proofs  of  authentication.  Scanned  images  of 
original  signatures  and  notari2ation  were  deemed  to  be  sufficient  for  legal 
admissibility  of  the  record. 

For  each  document,  the  prototype  provides  a  data  entry  screen  to  capture 
information  about  the  document  itself  For  example,  if  a  map  is  submitted 
to  the  Agency  with  an  application,  the  data  entry  screen  for  a  map 
document  allows  for  the  entry  of  such  information  as  the  type  of  map  (e.g. 
survey  map,  sketch,  wetlands  map),  as  well  as  the  map  scale,  the  map 
creator,  and  the  date  the  map  was  created.  As  documents  are  scanned  into 
the  system,  they  are  attached  or  related  to  the  appropriate  project  record. 
Figure  8  shows  the  types  of  documents  that  can  be  accommodated  by  the 
prototype  system.  The  bold- face  type  on  some  of  the  document  types 
indicates  that  there  is  a  document  of  that  type  in  the  project  record.  This 
fiinctionality  captures  information  about  the  components  of  a  record  as 
specified  earlier  by  use  of  the  Record  Level  of  the  RREC. 


Data  entry  screens 


The  data  entry  screens  were  designed  using  Visual  Basic.  They  are 
structured  in  a  consistent  format  and  operate  in  a  manner  similar  to 
Windows  applications.  For  those  elements  or  attributes  with  pre-defined 
values  such  as  town,  county,  project  type,  and  map  type,  drop-down  menus 
are  provided  to  decrease  data  entry  time  and  increase  accuracy.  Within  each 
data  entry  screen,  key  information  elements  are  defined  as  required,  and  the 
completion  of  the  data  entry  for  that  screen  requires  that  values  for  these 
fields  be  provided. 
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Workflow  -  staff  assignment  and  project  routing 


The  workflow  component  allows  for  the  assignment  of  different  types  of 
staff  to  a  project.  For  example,  when  creating  a  new  project,  the  system 
allows  for  the  assignment  of  a  PRO  and  natural  resource  and  legal  staff. 

The  system  also  allows  for  the  assignment  of  individuals  to  receive 
notification  about  a  given  project.  This  feature  allows  individuals  who  have 
no  pre- defined  responsibility  or  assignments  within  a  project  to  be  kept 
posted  on  project  progress.  The  workflow  component  also  routes  a  project 
record  through  the  process  after  an  individual  has  completed  a  step  or  sub¬ 
task  within  the  workflow  As  people  sign  off  on  a  task,  they  are  allowed  to 
provide  comments  or  notes  that  can  be  read  by  the  next  individual  in  the 
process.  The  project  record  moves  to  the  next  step  in  the  process  based 
upon  the  value  selected  upon  sign-off  The  diagrammatic  representation  of 
the  workflow  for  the  minor  project  permit  process  is  shown  in  Figure  9. 
The  workflow  diagram  can  be  used  to  identify  where  in  the  process,  a  given 
project  is  at  any  point  in  time.  The  workflow  software  also  provides  a 
narrative  Hst  of  the  steps  that  have  been  conducted  including  the  start  and 
finish  time  for  the  step  and  the  individual  who  conducted  it.  The  workflow 
functionality  can  also  be  used  to  address  records  management  requirements 
associated  with  authorizations  for  modifications  to  a  record.  While  not 
fully  implemented  in  the  prototype,  the  software  has  the  capability  to  allow 
deletions,  additions,  or  modifications  to  a  project  record  or  to  individual 
record  components  based  on  where  the  project  is  in  the  overall  review 
process  or  other  conditions. 

Figure  9.  Minor  project  review  workflow 
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Forms  generation 


The  forms  generation  feature  serves  a  number  of  purposes.  First,  it 
decreases  staff  time  in  repeatedly  typing  the  same  information  across 
documents  related  to  a  specific  project.  Second,  it  minimizes  the  potential 
for  error  by  drawing  upon  attribute  values  already  in  the  database.  Third, 
the  use  of  standard  clauses  increases  the  consistency  of  permits  and  AIRs 
(assuming  the  Agency  staff  reach  consensus  about  standard  language  for 
use  in  the  system). 

The  prototype  is  designed  so  that  relevant  values  entered  into  the  system 
are  automatically  placed  in  the  template  for  the  document  type  under 
development.  Additionally,  both  permits  and  AIRs  contain  some  set  of 
standard  language.  The  system  provides  a  pick  list  or  menu  of  these 
standard  clauses  that  can  automatically  be  added  to  a  document  under 
development.  Once  this  language  is  added  in  the  data  entry  screen,  it  can 
be  modified  if  necessary,  either  within  the  data  entry  screen  or  within  the 
document  itself  Figure  10  shows  an  example  of  a  document  creation 
screen  for  an  AIR.  This  screen  shows  the  menu  choices  for  items 
requested  in  an  AIR  and  also  provides  data  entry  points  for  other 
information  that  will  be  placed  into  the  document. 


Figure  10.  Forms  generation 
feature 
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As  indicated  above,  any  information  needed  for  the  document  that  is 
already  in  the  database,  will  automatically  be  called  up  and  placed  in  the 
appropriate  place  in  the  document.  Following  the  creation  of  the 
document,  the  user  has  two  choices.  One  is  to  print  the  document  to  a  file 
which  will  create  an  actual  electronic  file  of  the  document  that  can  then  be 
attached  to  the  project  record.  The  second  choice  is  the  print  option  which 
sends  the  document  to  a  printer  so  that  it  can  be  mailed  to  an  applicant.  In 
those  cases  where  the  document  has  to  be  signed  or  notarized  by  APA  staff 
per  legal  or  regulatory  requirements,  the  signed  and  notarized  original  can 
be  scanned  into  the  system  and  attached  to  the  project  record. 


Search  capabilities 


Perhaps  one  of  the  most  useful  features  of  the  system  in  terms  of 
improving  access  to  records  at  APA,  is  the  search  and  retrieval  capability. 
This  feature  allows  the  user  to  search  at  either  the  document  level  or  the 
project  level  based  on  any  attributes  contained  in  the  database.  The 
interface  supports  simple  or  complex  queries  that  can  be  developed  easily 
using  pull  down  menus.  In  much  the  same  way  that  the  data  entry  screens 
were  developed,  the  search  screens  allow  for  the  selection  of  attributes  on 
which  one  can  search.  For  those  attributes  with  pre-defined  values,  once 
the  attribute  is  selected,  the  available  values  are  presented  for  selection  in 
the  search.  Once  a  search  is  developed  and  submitted  to  the  system,  the 
records  or  documents  that  meet  the  search  criteria  are  listed  in  the  bottom 
of  the  search  screen.  If  the  search  was  conducted  at  the  record  level,  the 
search  results  will  show  aU  of  the  records  that  meet  the  search  criteria.  By 
double-cUcking  on  a  given  record,  all  of  the  document  types  contained 
within  that  record  will  be  displayed.  By  double-clicking  on  a  document 
type,  all  of  the  actual  documents  or  files  of  that  document  type  will  be 
displayed.  Double-clicking  on  a  specific  document  or  file  invokes  the 
Intergraph  Redline  tool  which  allows  for  the  viewing  of  a  particular 
document.  Figure  11  shows  the  document  search  and  retrieval  screen. 


Document  viewing  and  mark-up  capabilities 

As  indicated  above,  the  prototype  supports  the  viewing  of  a  specific 
document  or  file  within  a  project  record  by  using  a  product  that  allows  for 
the  viewing  of  70  different  types  of  file  formats.  This  is  a  particularly 
useful  tool  from  a  records  management  and  archival  perspective  because  it 
allows  a  user  to  view  documents  created  in  a  multitude  of  file  formats 
across  a  range  of  software  packages  without  having  to  maintain  the  native 
software  in  which  each  was  created.  This  has  advantages  for  both  current 
use  and  future  migration.  The  Redline  product  also  supports  non¬ 
destructive  mark-ups  to  documents  or  files.  It  allows  users  to  create  a  layer 
that  is  associated  with  a  given  file  without  changing  the  file  or  document 
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Figure  11.  Searching  project  review  records 


itself.  For  example,  a  user  may  create  a  layer  with  electronic  "post-it  notes" 
or  arrows  or  circles  or  other  annotations  that  can  be  viewed  by  other  users 
but  that  are  maintained  as  a  file  or  layer  distinct  from  the  original 
document.  This  feature  enhances  communication  about  documents  or  files 
among  users  while  maintaining  the  document  in  its  original  form.  These 
layers  can  be  viewed,  added,  modified,  or  deleted  separately  from  the 
original  document  or  file.  This  feature  is  particularly  useful  at  APA  where 
the  project  review  staff  may  want  to  draw  attention  to  a  specific  element  on 
a  map  while  communicating  with  natural  resource  staff,  for  example. 


Access  to  APA's  GIS 


The  prototype  system  also  supports  access  to  the  Agency’s  geographic 
information  system.  Information  contained  in  the  Agency’s  GIS  must  be 
accessed  in  the  project  review  process.  Using  Intergraph’s  GeoMedia 
product,  users  can  access  digital  spatial  data  independent  of  the  software 
with  which  it  was  created.  This  tool  allows  for  the  overlay  of  multiple  map 
layers  and  automatically  adjusts  scales  and  projections.  Following  access  to 
and  analysis  of  map  layers,  the  system  wUl  allow  for  the  capture  of  the 
screen  or  analysis  results  into  a  project  record  and  information  about  the 
resulting  document  or  screen  capture  can  be  input  using  the  data  entry 
screen  for  map  type  documents. 
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Archival  function 


As  shown  in  Figure  7  the  last  step  in  the  minor  project  review  process  is 
the  archival  function.  This  step  is  conducted  at  a  pre-set  interval  after  the 
project  has  been  completed.  At  this  point  in  the  process,  the  individual 
responsible  for  archiving  project  records  may  remove  any  unnecessary 
documentation  from  a  project  record  and  move  it  into  an  archival  vault. 
Once  a  project  record  is  inside  the  vault,  it  cannot  be  changed.  This  feature 
ensures  that  records  are  not  modified  after  a  transaction  is  complete. 

Prototype  delivery,  training,  and  testing 

The  prototype  system  was  deUvered  to  APA  in  March  1998,  and  was 
accompanied  by  presentations  of  the  prototype  functionality  to  the  full 
staff  and  two  levels  of  user  training.  One  level  focused  on  the  functionality 
of  the  prototype  within  the  minor  project  workflow  and  was  provided  to 
those  staff  who  work  directly  on  the  project  review  process.  The  second 
type  of  training  demonstrated  the  use  of  the  prototype  for  accessing 
project  records  for  secondary  use  in  the  Agency  and  focused  on  the 
prototype’s  search  and  retrieval  capabilities.  A  second  training  review 
session  was  held  in  June  to  train  staff  who  were  not  available  during  the 
prior  training  sessions. 

Several  of  the  Project  Review  Officers  participated  in  the  testing  of  the 
prototype  along  with  one  of  the  Directors  of  Regulatory  Programs, 
support  staff,  and  representatives  from  both  legal  and  natural  resources. 

All  evaluation  participants  were  asked  to  use  the  prototype  and  think  about 
its  features  and  functionality  in  terms  of  improvements  to  the  way  they  do 
thek  own  work.  They  were  asked  to  envision  how  the  system  would  help 
specifically  within  the  project  review  process  and  more  generally  about  how 
access  to  the  records  and  information  in  the  system  would  support  other 
processes  at  the  Agency. 

During  the  first  training  session,  several  project  applications  that  had  just 
been  received  by  the  Agency  were  input  into  the  system.  All  of  the  project 
documents  such  as  the  application,  maps,  and  deeds  were  scanned  and  the 
information  in  and  about  the  documents  was  input  into  the  system.  Staff 
were  assigned  to  work  on  each  of  the  projects  so  that  a  test  could  be 
conducted  of  routing  a  project  through  the  system.  The  individuals 
participating  in  the  training  were  asked  to  run  several  projects  through  the 
system  while  maintaining  parallel  paper  processes. 

At  the  time  of  this  report  the  Agency  is  continuing  to  test  the  prototype. 
Preliminary  feedback  collected  during  the  project  indicated  that  the 
prototype  successfully  demonstrated  the  potential  value  of  workflow  and 
document  management  technologies  to  meet  Agency  goals.  It  also 
generated  significant  interest  in  the  potential  value  of  developing 
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standardized  permit  conditions  and  AIRs,  and  in  establishing  a  definition 
of  a  legal  minimum  record  for  the  Agency.  Testing  of  the  prototype  also 
served  to  identify  to  the  Agency  staff  the  necessary  management  and  policy 
changes  that  would  be  required  within  the  Agency  to  complement  a  full 
system  implementation,  especially  the  need  for  changes  in  the  way 
individuals  conduct  then  work  within  an  automated  workflow.  They  were 
also  able  to  assess  the  relative  merits  of  managing  workflow  electronically 
versus  managing  it  through  the  adoption  of  standard  policies  and  practices. 
The  prototype  also  served  to  bring  the  issues  related  to  effective  records 
management  to  the  attention  of  the  Agency  Board. 
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Chapter  4 


Reflections  on  the  Tools 


This  chapter  provides  a  brief  analysis  of  the  effectiveness  of  the  functional 
Requirements  and  the  RRAIT  in  the  context  of  their  use  with  the 
Adirondack  Park  Agency.  It  also  makes  recommendations  for  future  users 
and  identifies  several  avenues  for  additional  testing  and  research. 


Preliminary  conclusions  about  the  effectiveness  of  the  tools 

Overall,  the  use  of  the  practical  tools  served  to  identify  a  comprehensive 
set  of  records  management  requirements  and  options  for  addressing  them 
in  the  context  of  developing  system  specifications  to  support  APA’s  minor 
project  review  process.  The  tools  were  seamlessly  integrated  into  the 
system  design  process  and  resulted  in  the  identification  of  technical 
specifications  and  opportunities  for  improving  customer  service  through 
improved  access  to  Agency  records. 

The  process  of  using  the  tools  with  APA  resulted  in  the  identification  of  a 
number  of  critical  management  and  policy  issues  that  must  support  a  fuU 
system  implementation.  In  some  cases,  these  issues  had  previously 
surfaced  in  other  contexts  at  the  Agency.  The  process  of  applying  the  tools 
brought  these  issues  to  the  forefront  so  that  they  could  be  addressed  in  a 
structured  fashion. 


Bringing  the  record  to  the  forefront  of  system  design  activities 

In  general,  the  use  of  the  tools  served  to  shift  the  focus  of  system  design 
and  development  away  from  technology  and  toward  the  capture, 
maintenance,  and  ongoing  use  of  the  Agency’s  business  records.  The  tools 
embedded  the  importance  of  the  record  into  the  system  development 
process  from  the  perspective  of  both  users  and  system  developers.  The 
focus  on  the  minor  project  record  was  readily  adopted  by  both  APA  staff 
and  the  corporate  partner  system  developers. 

The  use  of  the  RREC  firmly  established  the  concept  of  'record’  as  the 
centerpiece  of  the  system  design  efforts  and  further  brought  the 
maintenance  and  ongoing  accessibility  of  records  to  the  forefront  of  the 
system  design  and  development  process.  During  system  design  activities, 
the  concept  of  a  record  was  translated  into  a  'file  folder’  object  within  the 
structure  of  an  object-oriented  data  model.  This  conceptual  translation 
was  easily  understood  by  all  staff  involved  in  the  process.  The  answers 
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obtained  through  the  use  of  the  Record  Level  of  the  RREC  were  direcdy 
translated  into  the  development  of  the  underlying  data  model  for  the 
prototype.  This  data  model  was  a  critical  element  of  subsequent  system 
design  activities. 


Identifying  electronic  records  functionality  as  part  of  system  design 

The  business  requirements  that  underlie  the  records  management 
requirements  drove  the  selection  of  workflow  and  document  management 
as  appropriate  supporting  technologies.  Workflow  functionality  maps 
directly  to  the  records  capture  requirements  identified  by  the  Business 
Process  Level  of  the  RREC.  The  workflow  capabilities  of  the  prototype 
incorporated  these  requirements  as  rules  about  who  can  modify  which 
parts  of  a  record  and  at  what  points  in  the  process.  Document 
management  technology  was  used  in  the  prototype  to  support  records 
access  and  maintenance.  These  two  technologies,  implemented  in  a  full 
system,  would  support  the  necessary  records  management  functionality  for 
the  Agency. 

The  Record  Level  of  the  RREC  poses  questions  associated  with  ongoing 
internal  and  external  secondary  access  to  project  records.  The  answers  led 
to  the  selection  of  technologies  that  allow  for  the  viewing  of  diverse 
document  types,  regardless  of  their  native  format  or  creating  software, 
through  the  use  of  a  single  viewing  tool.  This  system  feature  also  prompts 
consideration  of  migration  issues  identified  through  the  use  of  the  System 
Level  of  the  RREC. 

The  project  prototype  demonstrated  that  the  technologies  exist  to  support 
the  necessary  functionality  of  a  workflow  and  document  management 
system  to  address  records  management  and  archival  requirements. 
Document  management  technologies  are  available  to  handle  multiple 
document  types,  scanning  and  indexing,  complex  workflow  with  branching 
and  condition  statements,  electronic  signatures,  and  the  ability  to  integrate 
these  within  an  existing  technical  infrastructure.  However,  not  every 
organi2ation  has  the  know-how,  infrastructure,  or  specific  tools  to  take 
equal  advantage  of  these  capabilities.  This  variability  in  organizational 
capabilities  underscores  the  value  of  the  RRAIT  which  is  technology- 
independent  and  views  a  system  from  a  business  process  perspective. 


Creating  records  that  support  legal  and  evidentiary  needs 

The  tools  supported  the  identification  of  aU  authenticity  requicements  tied 
to  the  minor  project  review  process  including  legal  admissibility.  These 
requirements  were  mapped  from  the  Business  Process  Level  to  the  Record 
and  System  Levels.  However,  many  of  the  authenticity  and  evidentiary 
needs  could  not  be  implemented  by  technology  alone  and  must  be 
supported  by  appropriate  management  practices  and  agency  policies. 
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Creating  records  that  are  accessible  and  usable  over  time 


Use  of  the  tools  at  APA  demonstrated  that  the  Business  Process  Level  of 
the  RREC  helps  organizations  identify  the  specific  record  components  that 
must  be  captured  at  each  step  during  the  course  of  a  transaction.  The 
Record  Level  addresses  the  need  for  access  to  records  over  time.  The 
RRIC  can  then  be  used  to  identify  technology  and  other  mechanisms  to 
ensure  that  records  are  appropriately  captured  and  that  they  remain 
accessible  for  both  current  and  future  use. 


Integrating  diverse  documentation  into  records 

The  Business  Process  Level  of  the  RREC  helped  APA  identify  the  diversity 
of  forms  and  formats  that  a  system  must  accommodate.  The  RRIC 
facilitated  the  identification  of  the  technical  strategies  that  can  be  used  to 
ensure  that  the  required  forms  and  formats  are  integrated  into  a  record  and 
accessed  over  time.  For  purposes  of  the  APA  prototype,  document 
management  and  imaging  technologies  were  used  to  achieve  this 
integration.  The  viewing  tools  in  particular  were  chosen  for  their  ability  to 
provide  ongoing  access  to  documents  created  in  a  variety  of  formats  using 
a  diversity  of  software  packages. 


Identifying  essential  records  policies  and  management  practices 

The  tools  facilitated  the  identification  of  important  management  and  poKcy 
strategies  to  ensure  that  records  management  requirements  are  met  with  an 
electronic  system.  As  in  many  other  organizations,  these  issues  appear  to 
present  the  most  difficulty  at  APA  as  their  content  and  execution  depend 
on  organizational  consensus  about  the  way  work  should  be  done. 

For  example,  APA  needs  to  establish  a  definition  of  a  minimum  legal 
record  for  a  project  transaction  as  well  as  a  list  of  components  that  should 
be  maintained  in  a  record  after  a  transaction  has  been  completed.  Policies 
are  also  needed  regarding  which  of  those  components  are  releasable  and 
not  releasable  under  FOIL.  The  business  process  improvement  effort 
highlighted  the  need  to  shift  from  a  individualistic  style  of  work  to  more 
consistent  processes  across  project  review  staff  System  maintenance, 
security,  and  user  access  were  identified  as  critical  management  and  poUcy 
issues  associated  with  system  implementation.  Finally,  the  prototype,  with 
its  automatic  forms  generation  capability,  pointed  out  the  need  for 
consensus  about  standard  language  for  such  documents  as  permits  and 
Additional  Information  Requests. 
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Strengths  and  weaknesses  of  the  Functional  Requirements 
and  the  RRAIT 


The  test  of  the  tools  at  APA  and  theit  review  by  the  Advisory  Committee 
and  outside  experts  revealed  both  strengths  and  weaknesses  that  future 
users  should  consider. 


Strengths 


The  functional  Requirements  present  records  management  requirements  in  a 
way  that  is  understandable  to  both  program  managers  and  technical  staff. 
They  are  system-  and  business-process  focused,  which  means  that  both 
practitioners  and  system  developers  can  easily  relate  to  them.  The  language 
is  clear  and,  perhaps  more  important,  the  requirements  comprise  a  concise 
set  of  standards  that  are  readily  adop table  by  busy  managers  and 
professionals  in  all  kinds  of  organizations. 

The  greatest  strength  of  the  REAIT  is  its  focus  on  the  business  process 
and  business  objectives.  Substantial  positive  feedback  was  received  from 
practitioners  as  well  as  records  managers  and  archivists  about  using  the 
business  process  as  the  focus  for  records  management  issues.  Practitioners 
indicated  that  this  manner  of  presentation  enabled  them  to  understand  the 
importance  of  records  management  requirements  in  terms  of  the  issues 
that  are  critical  to  them  in  conducting  their  work.  Records  management 
professionals  indicated  that  this  approach  helps  ensure  effective 
communication  with  practitioners  about  records  management  issues. 

The  Business  Process  Level  of  the  RREC  was  found  to  facilitate  the 
identification  of  opportunities  for  business  process  improvement.  More 
specifically,  the  questions  that  focus  on  whether  the  record  is  modified  or 
changed  in  the  various  steps  in  the  process  aid  in  the  identification  of  steps 
that  can  be  eliminated  or  modified.  The  differentiation  among  process 
steps  required  by  law  or  regulation  from  those  based  on  professional  best 
practices  or  agency  practices  helps  in  the  assessment  of  steps  or  tasks  that 
are  candidates  for  change  or  elimination. 

Another  major  strength  of  the  RRAIT  is  its  abiUty  to  directly  translate 
records  management  requirements  into  user  and  system  requirements.  The 
responses  to  the  questions  in  the  Business  Process  and  System  Levels  of 
the  RREC  are  easily  communicated  to  system  developers  in  terms  of 
technical  specifications.  Additionally,  the  questions  that  focus  on  the 
documents  that  comprise  a  record  and  on  internal  and  external  access  to 
records  can  be  readily  translated  into  data  model  specifications.  The  tools 
call  attention  to  long-term  access  issues  such  as  migration  strategies  and 
meta  data  that  should  be  addressed  at  the  initial  system  design  stage  to 
avoid  high  costs  in  the  long  run,  or  worse,  loss  of  access  to  important  records. 
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The  REJC,  with  its  focus  on  implementation,  highlights  the  importance  of 
supporting  policy  and  management  strategies  —  critical  elements  that  often 
receive  little  or  no  attention  in  system  development  efforts. 

The  tools  have  the  versatility  to  deal  with  both  internal  and  external 
primary  and  secondary  access  to  records.  The  Business  Process  and 
Record  Levels  of  the  RREC  support  the  identification  of  access  needs 
from  the  perspective  of  internal  users  during  a  business  transaction  as  well 
as  internal  and  external  access  needs  after  the  transaction  has  been 
completed.  The  questions  are  designed  to  identify  the  components  of  a 
record  requited  by  each  of  these  user  types  as  well  as  their  preferred  or 
required  mechanisms  for  accessing  them.  The  tools  therefore  help  ensure 
that  the  value  of  information  collected  and  maintained  during  a  business 
process  will  be  maximized  across  aU  user  groups. 

Flexibility  of  use  was  another  observed  strength.  The  manner  in  which  the 
questions  are  asked  and  answered  can  be  tailored  for  use  across  different 
organizational  contexts.  While  we  strongly  recommend  that  the  Business 
Process  Level  of  the  RREC  be  used  in  conjunction  with  some  form  of 
business  process  analysis,  the  questions  in  the  other  sections  can  be 
obtained  using  a  variety  of  methods  such  as  surveys  and  interviews.  In 
short,  the  tools  provide  a  sound  framework  for  the  identification  of 
records  management  requirements  that  can  be  modified  to  suit  any 
organizational  setting 


Weaknesses 


Perhaps  the  biggest  weakness  of  the  tools  is  the  pre-condition  for  their  use. 
That  is,  an  organization  must  first  recognize  the  importance  of  its  business 
records  and  the  costs  and  risks  associated  with  ignoring  them.  Without  this 
foundation,  it  is  unUkely  that  an  organization  will  invest  the  time  and 
attention  to  detail  that  the  tools  demand. 

Second,  while  the  tools  support  the  comprehensive  identification  of 
records  management  requirements  and  mechanisms  for  addressing  them, 
the  degree  to  which  they  are  implemented  depends  on  the  organization’s 
readiness  and  wiUingness  to  change.  Change  means  more  than  new 
information  systems;  it  requires  supporting  management  and  policy 
strategies  as  well  as  an  understanding  of  the  degree  to  which  the 
requirements  can  be  addressed  by  the  chosen  technologies.  In  short,  while 
the  tools  support  the  identification  of  requirements,  the  factors  that 
surround  their  implementation  determine  the  ultimate  level  of  success. 

Another  limitation  has  to  do  with  technology  selection.  While  the  tools 
provide  a  framework  for  the  identification  of  technology  requirements, 
they  do  not  address  the  actual  selection  of  hardware  and  software.  The 
tools  emphasize  the  selection  of  technology  solutions  that  maximize  inter¬ 
operability  and  adherence  to  standards,  but  they  are  not  designed  to 
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support  product  selection.  Rather,  they  help  organizations  identify  the 
functionality  that  is  required  in  a  system  to  support  records  management 
requirements.  Selection  of  specific  products  to  provide  the  necessary 
functionality  must  be  based  on  myriad  factors  which  include  existing 
infrastructure  (both  technical  and  organizational),  cost,  and  expected 
benefits. 


Suggested  context  for  use 

One  of  the  most  critical  factors  for  effective  use  of  the  tools  is  getting  the 
right  people  to  answer  the  questions.  All  the  internal  and  external  primary 
and  secondary  users  of  the  records  that  will  be  created  and  maintained  by 
an  information  system  should  be  represented.  While  only  a  sample  of  each 
user  type  may  be  involved  in  answering  the  questions,  it  is  critically 
important  that  all  of  the  types  or  groups  of  users  be  consulted.  It  may  be 
necessary  to  bring  legal  staff  or  executive  management  into  the  process. 
Legal  staff  can  assist  in  the  identification  of  statutory  or  regulatory 
requirements,  while  executive  level  staff  will  need  to  be  involved  in  the 
development  of  policy  and  management  strategies.  Individuals  with 
knowledge  of  the  professional  practices  associated  with  a  given  process  are 
also  important  participants.  System  development  or  technology  experts  can 
also  play  an  important  role  in  addressing  the  questions  and  providing 
information  about  product  capabilities  in  supporting  records  management 
requirements.  Not  all  of  the  players  are  required  during  the  entire  process; 
some  may  be  brought  in  to  assist  as  different  questions  are  being  addressed. 
However,  identifying  and  involving  aU  key  players  at  the  appropriate  point 
in  the  process  is  critically  important  to  the  successful  use  of  the  tools. 

As  discussed  earher,  several  methods  can  be  used  to  answer  the  questions 
in  the  RRAIT.  We  strongly  recommend  that  the  Business  Process  Level 
questions  be  answered  in  the  context  of  a  business  process  analysis  or 
improvement  activity.  The  methods  for  answering  questions  in  other 
sections  should  be  selected  for  their  compatibility  with  the  organization’s 
skills  and  time  schedules,  and  their  ability  to  rninimize  the  total  cost  of  the 
information  collection  process. 

We  strongly  recommend  that  technology  awareness  activities  be  conducted 
in  conjunction  with  the  use  of  the  tools.  Product  reviews,  vendor 
presentations,  and  conferences  focused  on  technology  appKcations  are  all 
ways  to  increase  awareness  of  technology  capabilities  and  limitations 
among  the  staff  who  will  work  with  the  new  system.  These  kinds  of 
activities  increase  understanding  of  the  strengths  and  weaknesses  of 
technology  types  and  specific  products.  A  broad  appreciation  for  what 
technology  can  and  cannot  do  wiQ  help  the  organization  make  appropriate 
technology  choices. 
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Additional  research  and  testing  of  the  tools 

Evaluation  of  the  tools  developed  in  this  project  is  limited  by  the  fact  that 
the  information  system  did  not  go  beyond  the  prototype  phase.  Without 
experience  in  a  full  system  implementation,  we  can  make  only  the 
preliminary  observations  above.  A  more  robust  test  of  the  tools  would 
require  a  much  longer  period  of  time  and  would  involve  using  the  tools  to 
conceptualize  and  design  a  full  system,  implementing  the  system  in  an 
operational  environment,  and  testing  the  degree  to  which  the  records 
management  issues  have  been  addressed. 

Additionally,  the  tools  have  been  tested  in  one  state  agency  using  one  set  of 
delivery  methods.  Additional  research  and  evaluation  activities  should  be 
conducted  with  other  government  agencies  and  with  private  sector 
organizations  using  a  variety  of  delivery  methods  to  confirm  the 
generalizeability  of  the  framework. 

Lastly,  the  project  results  strongly  suggest  that  the  development  of 
appropriate  management  and  policy  strategies  is  one  of  the  biggest  barriers 
to  implementing  systems  that  meet  records  management  requirements. 
Therefore,  additional  research  to  confirm  this  observation  would  be  of 
great  value,  as  would  research  that  identifies  and  tests  mechanisms  for 
overcoming  these  barriers. 
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Chapter  5.  Value  of  the  Project 


Value  to  the  archives  and  records  management  community 


♦  The  project  successfully  extended  theory  to  practice.  It  drew  from  the 
theoretical  foundations  of  the  profession  and  transformed  them  into 
categories  of  requirements  that  are  usable  and  implementable  in  the 
context  of  organizational  operations.  The  practical  tools  are  robust 
and  understandable  by  practitioners  in  both  the  public  and  private 
sectors. 

♦  The  project  emphasis  on  practical  tools  and  the  importance  of  hnking 
records  management  issues  to  organizational  business  processes 
provides  a  mechanism  for  improved  communication  between  records 
management  professionals  and  practitioners.  The  tools  provide  a 
common  language  and  foundation  for  discussions  of  records 
management  issues  in  the  context  of  work  that  is  critical  to 
organizations  that  are  developing  information  systems. 

♦  The  project  demonstrated  that  the  technology  to  support  the 
integration  of  records  management  and  archival  requirements  into  an 
information  system  is  currently  available.  However,  appropriate 
management  and  policy  strategies  must  also  be  identified  and 
implemented  to  complement  these  technologies. 

♦  The  project  products  have  been  shared  widely  in  interim  form  and  are 
akeady  being  used.  For  example,  the  International  Records 
Management  Trust  in  London  used  them  as  a  framework  for  a  needs 
analysis  focused  on  records  management  in  a  paper-based 
environment.  They  were  also  adopted  for  use  by  the  records 
management  staff  at  a  leading  banking  institution. 

Value  to  NHPRC 

♦  The  project  built  upon,  integrated,  and  extended  the  results  of  several 
previous  NHPRC-funded  projects.  As  a  result,  the  broader  community 
of  researchers,  and  records  and  archives  professionals  now  have 
methods  and  tools  to  support  the  management  and  preservation  of 
electronic  records  that  are  grounded  in  theory  and  tested  in  practice. 
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♦  The  project  provided  NHPRC  the  opportunity  to  leverage  its  funding 
resources  to  reach  a  new  and  diverse  practitioner  community.  Within 
that  community,  the  project  increased  awareness  of  NHPRC  and  its 
interest  in  and  support  for  the  development  of  practitioner- oriented 
tools. 


Value  to  recordkeeping  organizations  in  all  sectors 

♦  The  absence  of  methodologies  that  incorporate  electronic 
recordkeeping  requirements  has  been  a  key  barrier  to  the  effective 
development  of  information  systems  that  also  meet  records 
management  requirements.  This  project  dehvered  a  generali2able 
methodology  to  practitioners  to  overcome  this  barrier. 

♦  The  prototype  system  demonstrated  the  importance  and  the  feasibility 
of  incorporating  records  management  requirements  into  the  system 
design  and  development  process  rather  than  developing  costly  changes 
after  a  system  has  been  put  in  place.  It  also  demonstrated  that 
currendy  available  technology  can  provide  this  capability  for  a  range  of 
business  purposes. 

♦  The  project  raised  awareness  about  the  nature  and  extent  of  planning 
required  to  include  records  management  functionality  in  new 
information  systems. 


Value  to  the  Adirondack  Park  Agency 

♦  As  a  result  of  the  project,  the  APA  Commissioners  and  other 
stakeholders  in  the  Park  recognize  the  important  contribution  an 
electronic  records  management  program  can  make  toward  the 
achievement  of  APAs  mission  to  preserve  the  quality  and  vitality  of  life 
in  the  Park.  These  important  constituencies  now  have  a  deeper 
understanding  of  the  direct  and  indirect  benefits  of  maintaining  access 
to  electronic  records  to  support  Agency  operations  and  performance 
measurement. 

♦  The  project  demonstrated  the  importance  of  taking  user  perspectives 
and  requirements  into  account  in  implementing  technology  solutions. 
All  stages  of  planning,  design,  and  implementation  of  the  prototype 
incorporated  both  management  and  user  perspectives  and 
requirements.  As  a  result,  the  project  effectively  translated  electronic 
records  management  concepts  into  usable  terms  in  the  context  of  the 
Agency’s  business  process. 
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♦  The  business  process  analysis  activities  resulted  in  a  common 
understanding  of  the  steps  involved  in  the  minor  project  review 
process  from  the  perspective  of  aU  of  the  individuals  involved  either 
directly  and  indirectly,  including  line,  management,  and  executive  staff. 
The  business  process  improvement  activities,  supported  by  the 
Business  Process  Level  of  the  RREC,  helped  identify  opportunities  for 
modifying  the  minor  project  review  process  in  order  to  improve 
customer  service.  Through  the  business  process  improvement 
activities  and  the  secondary  access  requirements  survey,  primary  and 
secondary  information  access  needs  were  also  identified  and  reflected 
in  the  prototype. 

♦  The  project  assisted  in  the  identification  of  important  policy  and 
management  strategies  that  must  be  addressed  in  support  of  full 
system  implementation. 

♦  The  project  provided  APA  staff  the  opportunity  to  work  with  the  latest 
technologies  to  support  workflow,  document  management,  and  GIS 
integration. 


Value  to  corporate  partners 

♦  The  project  provided  the  opportunity  for  Intergraph  Corporation  to 
evaluate  the  applicability  of  a  new  product  and  to  test  its  robustness 
and  versatility  in  a  complex  workflow  process.  The  prototyping 
experience  generated  ideas  for  new  applications,  enhancements,  and 
refinements. 

♦  The  project  provided  the  corporate  partners  the  opportunity  to  test  the 
integration  of  some  of  their  newest  products  in  solving  a  real  world 
problem  by  allowing  for  realistic  testing  of  the  openness  of  the 
products  and  their  ability  to  be  integrated  with  each  other  and  within 
an  existing  technological  environment. 

♦  Corporate  partners  had  the  opportunity  to  work  in  an  atmosphere  of 
research  and  experimentation  which  allowed  them  to  engage  in  a  joint 
problem  solving  effort  with  a  government  agency. 

♦  The  project  provided  substantial  information  dissemination 
opportunities  about  the  corporate  partner  products  used  in  the 
development  of  the  prototype  to  new  and  existing  customers. 
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Value  to  the  university  community 


♦  The  project  results  are  being  used  to  educate  archivists  and  records 
managers  about  possibilities  for  addressing  many  long  standing  electronic 
record  issues.  The  project  products  are  being  incorporated  into 
curricula  at  the  University  at  Albany,  the  University  of  Maryland,  and 
CathoUc  University  An  article  on  the  project  published  in  the  Bulletin  of 
the  American  Society  for  Information  Science  is  required  reading  in  a  Library 
Science  course  at  Catholic  University. 

♦  The  Models  for  Action  project  is  a  valuable  teaching  example  for 
archival  educators.  While  much  has  been  written  in  theory  about  the 
desirability  of  incorporating  archival  concerns  into  the  design  of 
electronic  recordkeeping  systems,  there  have  been  few  examples  of 
attempts  to  actually  do  so.  This  project  will  help  the  graduate  archival 
education  community  demonstrate  the  viability  of  archivists  taking  a 
broader  view  of  their  responsibilities  for  recordkeeping.  Because  it 
represents  a  true  collaboration  between  archivists.  Agency  staff,  and 
university-based  researchers,  the  project  offers  practicing  archivists  a 
useful  model  for  working  on  electronic  records  problems  in  their  own 
environments. 

♦  The  project  funding  provided  support  for  a  faculty  member  from 
Albany’s  Rockefeller  College  of  Public  Affairs  and  PoKcy  to  conduct  a 
two-day  cost  and  performance  workshop  with  APA  staff,  which  helped 
the  Agency  staff  envision  various  levels  of  fiiU  system  implementation 
based  on  their  experience  with  the  prototype. 

♦  The  project  funding  supported  two  Computer  Science  graduate 
assistants  for  two  years.  In  addition,  graduate  assistants  in  Information 
Science  and  PubUc  Administration  who  were  supported  by  CTG 
funding,  had  the  opportunity  to  participate  in  project  research  and 
planning,  design  and  development  of  the  prototype,  and  in  on-site 
work  at  APA.  A  student  intern  completed  her  second  year  MBA 
project  by  participating  in  the  design,  development,  documentation, 
and  evaluation  of  the  project  prototype. 
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Value  to  SARA 


♦  The  project  served  to  solidify  a  program  direction  and  perspective  for 
SARA’s  electronic  records  management  services  to  government 
agencies.  The  project  clearly  underscored  the  advantages  and 
continuing  need  to  focus  the  program  on  practical  tools  to  integrate 
electronic  records  management  into  the  normal  course  of  business, 
linking  records  management  with  other  business  concerns  using  a 
language  that  is  understandable  to  these  customers.  SARA  will  also 
continue  to  focus  its  services  on  system  development  and  records 
creation  as  well  as  the  maintenance  and  retention  of  electronic  records. 
It  will  continue  to  emphasize  a  customer  service  approach  to  records 
management  in  which  relevant  services  are  continually  developed  to 
address  the  issues  raised  by  the  rapidly  evolving  technological  and 
organizational  environment  of  state  and  local  government. 

♦  SARA  identified  new  ways  to  present  records  management  and  archival 
issues  so  that  government  technical  and  program  managers  could 
conceptually  integrate  them  with  other  business  and  technical  concerns. 
SARA  now  has  the  ability  to  put  records  issues  in  a  broader  business 
context  and  perspective. 

♦  The  project  provided  SARA  a  vehicle  for  educating  its  business 
partners,  government  agency  customers,  and  the  vendor  community 
about  records  management  issues.  The  project  generated  tremendous 
interest  among  government  officials,  demonstrated  by  the  over  200 
registrants  for  the  project’s  public  demonstration.  Many  others 
followed  the  project’s  progress  through  the  vehicles  of  the  newsletters 
and  Web  sites  of  the  New  York  State  Forum  for  Information  Resource 
Management,  CTG,  and  SARA. 

♦  The  Records  Requirements  Anaysis  and  Implementation  Tool  (RRAIT)  will  be 
integrated  into  SARA’s  array  of  services.  During  the  last  few  years, 
SARA  has  been  attempting  to  develop  staff  expertise  in  business 
process  analysis  and  improvement  (BPA/I)  techniques.  SARA  direct 
service  staff  will  be  trained  to  use  the  RRAIT  as  part  of  their  BPA/I 
‘tool  kit.’  The  functional  Requirements  and  the  RRAIT  will  then  be 
infused  in  SARA  training  and  other  pubKcations,  influencing  the  way  it 
presents  records  management  to  its  primary  customers,  state  and  local 
governments  in  NYS.  New  training  sessions  from  SARA  will 
incorporate  the  functional  Requirements  as  an  effective  communication 
tool  bridging  the  language  barrier  between  staff  at  SARA  and  the 
practitioner  community.  SARA  is  developing  a  BPA/I  workshop  for 
government  officials  that  wiQ  include  training  on  using  the  RRAIT.  A 
pilot  workshop  wUl  be  developed  and  tested  in  the  faU  of  .1998  and 
regular  BPA/I  workshops  will  begin  in  the  spring  of  1999.  The  project 
prototype  at  APA  will  likely  be  used  as  a  case  study  in  this  workshop. 
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♦  SARA  benefited  from  the  close  working  relationship  with  the  project 
team  including  consultants,  academics,  information  technology 
professionals,  and  information  technology  vendors.  These 
relationships  have  allowed  SARA  staff  to  gain  needed  familiarity  with 
important  sectors  of  the  information  technology  environment, 
positioning  it  to  influence  the  implementation  of  network-based 
technologies  in  State  and  local  government 


Value  to  CTG 


♦  The  research  activities  supported  by  this  project  further  strengthened 
the  Center’s  awareness  of  ways  in  which  archival  and  records 
management  issues  can  be  incorporated  into  the  information  systems 
development  process.  The  RRAIT  will  continue  to  be  used  to  support 
business  process  analysis  and  system  design  efforts  in  future  CTG 
projects.  For  example,  the  RREC  is  currently  being  used  in  CTG’s 
Usinginformation  in  Government 'Program  as  a  mechanism  for  helping  the 
participants  identify  the  information  needed  to  support  program 
evaluation,  policy  analysis,  and  decision  making. 

♦  The  project  provided  CTG  opportunities  to  work  with  a  new 
community  of  professionals  from  the  archival  and  records 
management  field.  In  particular,  the  project  strengthened  CTG’s 
working  relationship  with  SARA  and  introduced  the  staff  to  a  variety 
of  experts  whose  advice  will  continue  to  be  sought  in  the  future. 

♦  Throughout  the  project,  CTG  staff  developed  an  increased 
appreciation  for  the  issues  associated  with  secondary  access  to  valuable 
information  created  by  government  agencies.  As  a  result,  CTG 
submitted  and  received  funding  for  a  second  NHPRC  project,  Gateways 
to  the  Pasty  Present  and  Future:  Practical  Guidelines  to  Secondary  Uses  of 
Electronic  Records,  which  will  build  upon  the  results  of  Models  forA.ction. 
The  Gateways  project,  a  continuing  partnership  with  SARA,  will  focus 
more  specifically  on  records  management  issues  and  models  for 
maintaining  and  supporting  access  to  records  for  internal  and  external 
secondary  uses. 
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Appendix  A.  Project  participants 


Project  Advisory  Committee 

Pamela  Akison,  NYS  Department  of  Health 

Jerry  Barber,  NYS  Office  of  State  Comptroller 

Kevin  Belden,  NYS  Department  of  Taxation  and  Finance 

Betty  Borowsky,  Nassau  County  Health  Department 

Thomas  Clingan,  Albany  County  Clerk 

Ted  Collins,  Kodak/Boyle  Associates 

Ed  Donohue,  NYS  Workers  Compensation  Board 

Philip  Eppard,  School  of  Information  Science  &  Policy, 

University  at  Albany 

Ruth  Fraley,  NYS  Office  of  Court  Administration 

Stephen  Gallagher,  NYS  Bar  Association 

Thomas  Galvin,  Doctoral  Program  in  Information  Science, 

University  at  Albany 
Susan  Herrmann,  Key  Services 
Terry  Maxwell,  NYS  Forum  for  IRM 
Thomas  Mills,  State  Archives  &  Record  Administration 
Bruce  Oswald,  NYS  Office  for  Technology 
Will  Pelgrin,  NYS  Office  for  Technology 

Dixianne  Penney,  Center  for  the  Study  of  Issues  in  PubUc  Mental  Health 
Peter  Poleto,  NYS  Department  of  Motor  Vehicles 
Robert  Sandusky,  Key  Bank 

Greg  Sheppard,  Capital  District  Physician’s  Health  Plan 
Sam  Wear,  Westchester  County 


Corporate  Partners 

Audio  Visual  Sales  and  Service 
Hewlett-Packard 
Intergraph  Corporation 
Image  Conversion  Systems 
Oracle  Corporation 
MediaServ 

Microsoft  Corporation 
Sybase  Inc. 
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Adirondack  Park  Agency 


Christopher  Anderson,  Project  Review  Specialist 

John  Banta,  Director  of  Planning 

William  Curran,  Director  of  Regulatory  Programs 

Eleanor  Duffus,  Project  Review  Specialist 

Gary  Duprey,  Associate  Project  Review  Specialist 

Stephen  Erman,  Special  Assistant,  Economic  Affairs 

Daniel  Fitts,  Executive  Director 

Mitchell  Goroski,  Staff  Attorney 

Brian  Grisi,  Associate  Analyst,  Forest  Resources 

Nancy  Heath,  Principal  Clerk 

Edward  Hood,  Assistant  Director  of  Planning 

Richard  Jarvis,  Supervisor,  Project  Review 

Theresa  LaBaron,  Secretary 

Suzanne  McSherry,  Project  Review  Specialist 

Jim  Marrin,  Counsel 

George  Outcalt,  Associate  Project  Review  Specialist 
John  Quinn,  Associate  Project  Review  Specialist 
Colleen  Parker,  Project  Review  Specialist 
Barb  Rottier,  Associate  Counsel 
Thomas  Saehrig,  Project  Review  Specialist 
Henry  Savarie,  Senior  Natural  Resource  Planner 
Richard  Terry,  Senior  Attorney 


state  Archives  &  Record  Administration 

Alan  Kowlowitz,  Senior  Archivist 

Betsy  Maio,  Records  Management  Specialist 


University  at  Aibany 


Office  of  Telecommunications 

John  Rohrbaugh,  Professor,  Department  of  Public  Administration 
and  Policy 
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CTG  Staff  &  Students 


David  Connelly,  Graduate  Assistant,  Public  Adnainistration  &  PoHcy 

Ann  DiCaterino,  Manager,  Project  Support 

Darryl  Green,  Manager,  Project  Support 

Mballou  Kaba,  Graduate  Assistant,  School  of  Business 

Kristine  Kelly,  Project  Research  Manager 

Kai  Larsen,  Graduate  Assistant,  Information  Science 

Theresa  Pardo,  Project  Director 

Mei-Huei  Tang,  Graduate  Assistant,  Computer  Science 

Wen-Li  Wang,  Graduate  Assistant,  Computer  Science 

Derek  WerthmuUer,  System  Administrator 
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Appendix  B.  Archival  and  records  management 
expert  reviewers 


Margaret  Adams,  Center  for  Electronic  Records 

National  Archives  and  Records  Administration 

Richard  Barry,  Barry  Associates 

Philip  Bantin,  University  Archives,  Indiana  University 

David  Bearman,  Archives  &  Museum  Informatics 

Richard  Cox,  School  of  Library  and  Information  Science 
University  of  Pittsburgh 

Charles  Dollar,  School  of  Library,  Archival,  Informational  Studies 
University  of  British  Columbia 

Mark  Giguere,  National  Archives  and  Records  Administration 

Anne  Gilliland-Swetland,  Department  of  Library  and  Information  Science 
University  of  CaKfornia  at  Los  Angeles 

Margaret  Hedstrom,  School  of  Information,  University  of  Michigan 

Paul  Hedges,  State  Historical  Society  of  Wisconsin 

Richard  Kessner,  Horner  Library,  Babson  College 

Michael  Miller,  Office  of  IRM,  US  Environmental  Protection  Agency 

John  McDonald,  National  Archives  of  Canada 

Charles  Robb,  Kentucky  Department  of  Library  &  Archives 

Gregory  Sanford,  State  Archivist,  Vermont  State  Archives 

Kenneth  Thibodeau,  Center  for  Electronic  Records 

National  Archives  and  Records  Administration 

Robert  Williams,  Cohasset  Associates,  Inc. 
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Appendix  C.  Project  timeline 


Date 


Activity 


June  1995 

March  1996 
October  1996 
October  1996 
November  1996 

December  1997 
March  1997 
May  1997 
July  1997 
August  1997 

September  1997 
October  1997 
November  1997 
December  1997 
December  1997 
February  1998 
March  1998 

April  1998 
April  1998 
April  1998 
April  1998 
June  1998 
August  1998 


Grant  proposal  submitted  to  the  National  Historical  Publications  and  Records 
Commission 

Project  activities  begin 

Project  Concept  Paper  released 

First  Meeting  of  the  Project  Advisory  Committee 

Conducted  review  of  project  products  to-date  with  recognized  experts  in  archival 
and  records  management  discipline 

Interim  Product  Released  -  Functwnal  Requirements  Version  1 

First  Business  Process  Improvement  Workshop  at  the  Adirondack  Park  Agency 

Second  meeting  of  the  Project  Advisory  Committee 

Second  Business  Process  Improvement  Workshop  at  the  Adirondack  Park  Agency 

Interim  Product  Released  -  A  Survey  of  Key  Concepts  and  Issues  for 'Electronic 
Recordkeeping 

Partnership  with  Intergraph  established 

System  Overview  and  Functional  Specifications  defined 

Interim  Product  Released  -  An  Introduction  to  Workflow  Management  Systems 

Analysis  of  APAs  Additional  Information  Request  process 

Prototype  Development  Begins 

Interim  Product  Released  -  A  Survey  of  System  Development  Methodologies 

Prototype  delivered  and  installed  at  APA;  Staff  trained,  prototype  use  and 
evaluation  begins 

Cost  and  Performance  Workshop  with  the  staff  from  the  Adirondack  Park  Agency 

Interim  Product  Released  -  The  Records  Requirements  Analysis  and  Implementation  Tool 

Interim  Product  Released  -  Functional  Requirements  -  Final  Version 

Grant  Period  Ends 

Public  Demonstration  of  Results 

Final  Project  Report  Distributed 
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Appendix  D.  Information  dissemination  activities 


Date 

May  1997 
June  1997 

July  1997 
July  1997 
August  1997 
October  1997 
December  1997 

January  1998 
March  1998 

March  1998 
April  1998 

June  1998 
June  1998 
June  1998 

July  1998 
August  1998 
September  1998 


Activity 

Attended  Working  Meeting  on  Electronic  Records  in  Pittsburgh 

Article  about  the  project  was  pubKshed  in  the  June/July  1997  issue  of  the  bulletin  for  the 
American  Society  for  Information  Science 

Presentation  of  Project  Activities  at  URISA  "97 

Presentation  of  Project  Activities  at  NAGARA  "97 

Presentation  of  Project  Activities  at  SAA  "97 

Presentation  to  the  NYS  Office  for  Technology  Workflow  Working  Group 

Presentation  of  Project  Activities  to  Ken  Thibodeau,  Director,  Center  for  Electronic 
Records,  NAEA 

Presentation  at  the  NYS  Commissioner  of  Education’s  Quarterly  Review 

Presentation  at  ""The  Information  Ecosystem:  Managing  the  Life  Cycle  of 
Information  for  Preservation  and  Access”  sponsored  by  the  Northeast  Document 
Conservation  Center 

Presentation  to  Center  for  Electronic  Records,  NARA 

Presentation/Discussion  with  the  Chief  of  the  Records  Information  Systems  Unit, 
United  Nations 

Presentation  of  Project  Results  to  Adirondack  Park  Agency  Board 

Public  Demonstration  of  Project  Results  and  Prototype  to  NYS  organizations 

Presentation  to  Information  Policy  Class,  Professor  Bruce  Dearstyne,  Information 
Science  and  PoKcy  Program,  Rockefeller  College 

Presentation  of  Project  Results  at  URISA  "98 

Presentation  of  Project  Results  at  SAA  "98 

Presentation  of  Project  Results  at  GTC  East  "98 
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Appendix  E.  Records  Requirements  Analysis  and 
Implementation  Tooi  (RRAIT) 


The  RRAIT  is  comprised  of  two  parts:  the  Records  Requirements  'Elicitation 
Component  (RREC)  and  the  Records  Requirements  Implementation  Component 
(RRIC).  Combined,  these  components  facilitate  the  identification  and 
implementation  of  application-specific  records  management  requirements. 

The  RREC  facilitates  the  identification  of  records  management 
requirements  during  business  process  improvement  and  systems  analysis 
activities.  The  RREC  itself  is  divided  into  three  levels: 

♦  Business  Process  Level  -  focuses  on  those  records  management 
requirements  associated  with  the  business  process  that  is  to  be 
automated 

♦  Records  Level  -  captures  records  management  requirements 
associated  with  access  and  use  over  time,  for  both  the  record  in 
aggregate  and  its  component  parts 

♦  System  Level  -  focuses  on  how,  from  a  technical  standpoint,  the 
information  system  wiU  accommodate  the  integration  of  and 
ongoing  access  to  record  components 

The  RRIC  focuses  on  the  identification  of  management,  policy,  and 
technology  strategies  that  address  the  requirements  once  they  have  been 
identified. 
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Business  Process  Level 


Records  Requirements  Elicitation  Component 
_ Business  Process  Level _ 

1.  What  is  the  transaction  to  be  automated  (from  the  perspective  of  the  customer) _ 

2.  What  are  the  subtasks  associated  with  the  transaction?* _ 

3.  For  each  of  the  subtasks... _ 

_ I _ Basis  for  the  answer  _ 

I  Agency 

Best  policies  & 
Legal  Regulatory  Practices  practices 

A.  What  is  the  purpose  of  the  sub¬ 
task?  Is  it  intended  to  fulfill  a  legal, 

regulatory,  or  operational  purpose? _ 

1 .  Are  there  any  ^/vhen’  or  ’how’ 
requirements  for  the  transaction? 

(i.e.  time  clocks  or  standard 

professional  techniques) _ 

B.  What  other  documents  or 
information  need  to  be  accessed 

during  the  sub-task? _ 

C.  Is  the  record  of  the  transaction 

created  or  modified? _ 

1 .  If  yes,  at  what  point  in  the 
transaction  is  the  record  created  or 

modified? _ 

2.  Who  is  authorized  to  change  or 

modify  the  record? _ 

3.  What  is  the  content  of  the  record 
or  the  component  of  the  record 
created  or  added  during  the  sub- 

task? _ 

a.  Are  there  documents  or 
information  created  by  other 
systems  that  need  to  be  integrated 

into  the  record? _ 

b.  Is  there  any  information  about 
the  component  of  the  record  that 
needs  to  be  collected  and 

maintained? _ 

c.  Are  there  any  proofs  of 
authenticity  associated  with  the 
content  created  or  modified  during 
the  sub-task? 


*A  sub-task  starts  a  process  and  ends  with  a  decision  point  or  completes  the  transaction. 
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Steps  involved  in  using  the  Business  Process  Level  of  the  RREC 


♦  Gather  background  information  to  identify  records  management 
issues.  Interviews,  surveys,  and  focus  groups  are  useful  for  this 
step. 

♦  Create  a  process  model  or  diagram  that  presents  the  entire  business 
process  that  is  the  focus  of  the  analysis.  This  can  be  done  in  a 
group  setting  or  one  or  a  few  people  can  draft  the  diagram  for 
review  by  those  who  participate  in  the  business  process. 

♦  Conduct  a  workshop  or  group  decision  conference  with  all  staff 
involved  in  the  process  to  accomplish  the  following: 

♦  Develop  consensus  and  common  definitions  around  the 
process  diagram  representing  the  current  business  process. 

♦  Identify  sub-tasks  or  logical  breaks  in  the  process. 

♦  For  each  of  the  sub- tasks,  pose  the  questions  in  the  Business 
Process  Level  of  the  RREC  (careful  transcription  and 
organization  of  responses  is  critical). 

♦  Distinguish  wherever  possible,  whether  a  records  management 
requirement  is  associated  with  a  legal  or  regulatory 
requirement,  professional  or  agency  best  practice  or  policy. 

♦  Identify  areas  where  there  exists  uncertainty  in  the  responses 
and  identify  individuals  for  follow-up. 

♦  Based  on  the  responses,  begin  to  identify  options  for 
improving  the  business  process. 

♦  Translate  the  requirements  into  system  specifications^ 

♦  Hints: 

♦  Sub-tasks  that  result  in  no  change  in  the  record  are  likely  to 
add  no  value  to  the  process  and  may  be  candidates  for 
modification,  elimination,  or  movement  to  another  part  of  the 
process. 

♦  Minimizing  the  number  of  times  that  a  record  is  passed  back 
and  forth  between  staff  within  a  process  can  reduce  total 
transaction  time.  Attempt  to  identify  opportunities  for 
consolidating  task  work  within  a  pass. 

♦  Records  management  requirements  that  are  not  based  upon 
legal  or  regulatory  requirements  are  candidates  for 
modification  or  elimination.  For  each  of  the  identified 
requirements,  ask  the  questions  ‘Why  is  it  done?”  and  “Does  it 
need  to  be  done?” 


Page  76 


Center  for  Technology  in  Government 


Record  Level 


Records  Requirements  Eliciation  Component 

Record  Level 

1 .  What  are  the  current  components  of  a  complete  or  final  record  of  the  transaction? 

2.  What  are  the  minimai  components  to  provide  evidence  of  the  transaction? 

(if  you  went  to  court,  what  would  be  the  minimum  information  that  you  would  need?) 

3.  Are  there  any  laws,  regs,  or  professional  best  practices  that  specify  the  structure 
(including  medium,  format,  relationships)  of  the  record  of  the  transaction  or  any  of  its 
components? 

4.  What  information  needs  to  be  created  to  control,  manage,  and  access  the  record 
throughout  its  life-cycle?  (What  information  about  the  record  do  you  need  e.g.  who  created 
it  etc.) 

5.  For  each  of  the  components  of  the  record,  what  information  is  essential  to  access, 
verify  the  authenticity,  interpret  the  contents  etc. 

6.  During  what  other  Agency  business  processes  might  you  have  to  access  this  record? 

A.  For  each  of  the  business  processes,  what  components  of  the  record  need  to  be 
accessed? 

business  processes,secondary  uses,  v\/hat  are  the  most  efficient/effective  ways  of 
accessing  the  records  (i.e.  indexing)?* 

7.  Who  are  the  external  secondary  users  of  the  record? 

A.  What  components  of  the  record  do  external  secondary  users  require? 

B.  For  each  of  these  secondary  uses,  what  are  the  most  efficient/effective  ways  of 
accessing  components  of  the  records  (I.e.  Indexing)? 

C.  How  will  the  record  be  reproduced  to  meet  the  needs  of  internal  and  external 
secondary  users? 

D.  What  are  the  rules,  laws,  and  regs  that  restrict  or  open  access  to  these  records  to 
external  users? 

E.  If  these  records  are  covered  by  FOIL: 

For  those  components  of  the  record  that  the  Agency  wishes  to  restrict  access  to,  what 
category  of  exemption  does  the  component  fall  under? 

For  each  of  the  components,  what  format  are  they  currently  in  (e.g.  GIS,  database,  WP, 
paper-  forms  narrative  maps)  and  how  will  they  be  reproduced  for  distribution? 

8.  What  is  the  record  disposition  plan? 

9.  Who  is  responsible  for  authorizing  the  disposition  of  records? 

10.  Who  is  responsible  for  authorizing  the  development  or  changes  to  the  records 
disposition  plan? 

*  Identify  the  business  process  that  requires  the  most  robust  access  and  then  determine  if 
the  other  processes  require  additional  access  methods 

Unlike  the  Business  Process  Level  of  the  RREQ  there  is  no  one  recommended 
implementation  method  for  the  Record  Level.  Answers  to  these  questions  can  be  obtained 
through  interviews,  surveys,  or  group  decision  conferences.  The  most  critical  factor  in  using 
this  level  of  the  RREC  is  identifying  the  appropriate  individuals  to  supply  the  requited 
information. 
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Steps  involved  in  using  the  Record  Level  of  the  RREC: 


♦  Identify  all  the  internal  and  external  users  of  the  record  generated 
by  the  business  process.  If  necessary,  identify  a  representative 
sample  of  users  to  address  the  record  access  needs  questions. 

♦  Identify  and  gather  the  required  information  from  individuals 
within  the  organization  who  are  familiar  with  the  legal, 
jurisdictional,  and  professional  best  practices  associated  with  the 
record  of  the  transaction. 

♦  Identify  and  gather  the  required  information  from  individuals 
internal  or  external  to  the  organization  who  have  responsibility  for 
or  authority  with  respect  to  the  management  and  disposition  of 
records. 

♦  Translate  the  requirements  into  system  specifications. 


System  Level 


Records  Requirements  Elicitation  Component 
System  Level 


How  will  the  system  accommodate  the  required  integration  of  records  from  other  systems? 

What  other  systems  might  these  records  be  migrated  to? _ 

What  is  your  systems  migration  plan? _ 

For  each  of  the  technologies  being  used  to  support  the  business  process: _ 

What  are  the  metadata  requirements? _ _ 

What  are  the  industry  standards? _ 

What  are  the  jurisdictional  standards? _ 


Steps  involved  in  the  use  of  the  System  Level  of  the  RREC: 

♦  For  each  of  the  document  or  record  component  types,  identify 
how  the  system  will  support  its  integration  into  the  record.  In 
those  cases  where  the  record  component  can  not  be  included  into 
the  record  directly,  develop  an  indexing  and  storage  strategy  to 
identify  the  component  and  its  location  outside  of  the  record. 

♦  Identify  other  systems  that  the  records  may  be  exported  or 
migrated  to  over  time. 

♦  Develop  a  migration  plan  that  includes  consideration  to  each  of 
the  identified  document  or  record  component  types. 

♦  In  conjunction  with  the  use  of  the  RRIC,  described  below,  identify 
the  required  meta  data,  industry,  or  jurisdictional  (state,  local, 
federal)  policies,  procedures,  and  standards  that  must  be 
accommodated  by  the  system. 

♦  Translate  these  requirements  into  system  specifications. 
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RRIC 


Records  Requirement  Impfementation  Component  (RRIC) 


For  each  of  the  identified  records  management  requirements: _ 

Can  it  be  addressed  through  technology? _ 

If  yes.... 

will  policies  need  to  be  developed  or  changed? 

what  sorts  of  management  practices  will  be  required? _ 

If  no, 

What  policies  and  management  strategies  will  support  the  requirements? 


While  there  is  no  pre-defined  method  for  implementing  the  RRIC,  it  is  very 
useful  to  conduct  it  in  conjunction  with  technology  awareness  activities. 

We  recommend  an  iterative  process  of  technology  awareness,  feasibility 
assessment,  and  technology  selection.  This  approach  helps  the  organization 
understand  the  fuU  range  of  technology  options  and  their  costs  and 
benefits  as  part  of  the  determination  as  to  whether  records  management 
issues  should  be  addressed  by  management,  policy,  or  technology  strategies. 
Ideally,  an  organization  should  strive  to  maximize  the  use  of  technology, 
and  rely  less  on  human  factors  to  ensure  that  records  management  issues 
are  addressed.  However,  this  may  not  always  be  cost-effective  or  feasible. 
Therefore,  the  costs  and  benefits  of  technology  strategies  compared  to 
management  and  policies  strategies  should  be  addressed  as  a  component  of 
the  RRIC. 


Steps  involved  in  using  the  RRIC: 

♦  Gather  information  about  potential  technology  choices  to  support 
the  business  process  and  associated  records  management 
requirements. 

♦  Gather  information  on  such  costs  as  hardware,  software,  training, 
development,  system  integration,  development^  etc. 

♦  Assess  organizational  capabilities  or  organizational  readiness  for 
the  adoption  of  new  technology. 

♦  Conduct  an  analysis  of  the  feasibility  of  using  initially  selected 
technologies  to  address  the  records  management  requirements^ 

♦  Test  the  technological  capabilities  and  reassess  feasibility  for 
implementation. 

♦  Identify  required  complementary  poUcy  and  management  strategies 
to  support  the  identified  technology  components^ 

♦  Identify  individuals  within  the  organization  to  assist  in  the 
development  of  and  implementation  of  required  management  and 
policy  strategies. 
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♦  Hint: 


The  framework  below  is  a  useful  way  to  record  and  compare  the 
different  strategies  that  could  be  used  to  implement  records 
management  requirements; 


Comparison  of  Implementation  Strategies  for  Records  Requirements 


Strategies 
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Appendix  F.  Related  products 


Unless  otherwise  noted,  all  papers  are  available  on  the  CTG  Web  site  at 

http://www.ctg.albany.edu/projects/er/ermn.html 


Betsy  Maio.  A  Survey  of  Key  Concepts  and  Issues  for 'Electronic  Kecordkeepingy 
Models  for  Action  Project  Working  Memo  CTG.  MFA-001.  August  1997. 

A  review  of  technology  standards,  government  policies,  legal  principles  and 
best  practices  was  conducted  in  April  1996  addressing  key  issues  the  project 
expected  to  encounter  during  the  design  and  development  of  the  APA 
prototype.  This  report  outlines  the  results  of  that  survey  and  is  intended  to 
serve  as  an  introduction  to  key  concepts  and  to  guide  the  associated  choices 
which  APA  is  expected  to  face  as  they  move  from  a  largely  paper-based 
business  process  to  a  networked  document  management  and  workflow 
system. 


Ann  DiCaterino,  Kai  R.  Larsen,  Mei-Huei  Tang  and  Wen-Li  Wang.  An 
Introduction  to  Workflow  Management  Systemsy  Models  for  Action  Project 
Working  Memo  CTG.MFA-002.  November  1997. 

This  document  provides  an  introduction  to  Workflow  Management 
Systems.  Through  a  two-tiered  approach,  the  reader  is  first  exposed  to  a 
functional  review  of  workflow  systems,  including  definitions,  typical 
features,  benefits,  tradeoffs,  process  selection,  and  success  factors  for 
implementation,  followed  by  a  technical  overview  that  describes  a  method 
for  categorizing  workflow  products,  the  state  of  the  market,  and  emerging 
standards. 


Darryl  Green  and  Ann  DiCaterino.  A  Survey  of  System  Development  Process 
Modelsy  Models  for  Action  Project  Working  Memo  CTG.  MFA-003. 
February  1998. 

This  document  provides  an  overview  of  the  more  common  system 
development  Process  Models,  used  to  guide  the  analysis,  design,  development, 
and  maintenance  of  information  systems.  There  are  many  different 
methods  and  techniques  used  to  direct  the  life  cycle  of  a  software 
development  project  and  most  real-world  models  are  customized 
adaptations  of  the  generic  models.  While  each  is  designed  for  a  specific 
purpose  or  reason,  most  have  similar  goals  and  share  many  common  tasks. 
This  paper  explores  the  similarities  and  differences  among  these  various 
models  and  discusses  how  different  approaches  are  chosen  and  combined 
to  address  practical  situations. 
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Kristine  Kelly  and  Alan  Kowlowitz.  functional  Requirements  to  Ensure  the 
Creation,  Maintenance,  and  Preservation  of  Electronic  Records,  Models  for  Action 
Project  Working  Memo  CTG.  MFA-004.  April  1998 

This  document  introduces  one  of  the  foundations  for  the  Models  for  Action 
project,  the  Functional  Requirements  to  Ensure  the  Creation,  Maintenance, 
and  Preservation  of  Electronic  Records,  These  Requirements,  which  were 
based  on  the  results  from  the  Pittsburgh  Project,  outline  basic  standards  for 
sound  electronic  recordkeeping  practices  within  an  organization.  This 
paper  discusses  the  background,  development,  and  usage  of  the  Functional 
Requirements. 


Kristine  Kelly  and  Alan  Kowlowitz.  The  Records  Requirements  Analysis  and 
Implementation  Tool,  Models  for  Action  Project  Working  Memo  CTG.  MFA- 
006.  April  1998. 

This  document  describes  the  Records  Requirements  Analysis  and 
Implementation  Tool  (RRAIT)  one  of  the  key  products  developed  for  the 
Models  for  Action  project.  The  RRAIT  is  a  practical  tool  that  is  made  up  of 
two  components:  the  Records  Requirements  Elicitation  Component 
(RREC)  and  the  Records  Requirements  Implementation  Component 
(RRIC).  The  former  is  used  to  define  organizational  recordkeeping 
requirements  and  the  latter  is  used  to  identify  mechanisms  for 
implementing  those  requirements.  This  paper  examines  the  makeup  of 
these  tools  and  explores  how  the  two  are  used  in  conjunction  with  each 
other  to  define  and  implement  policy,  management,  and  technology 
mechanisms  to  implement  sound  electronic  recordkeeping  practices  within 
an  organization. 


Models  for  Action:  Developing  Practical  Approaches  to  Electronic  Records  Management 
and  Preservation  -  June/July  1997  issue  of  the  Bulletin  for  the  American 
Society  for  Information  Science,  located  at 

http://www.asis.org/Bulletin/Jun-97/aIbany.html 


Darryl  Green,  Mballou  Kaba,  Kai  Larsen,  and  Derek  WerthmuUer.  Models 
for  Action  Technical  Results  from  the  APA  Prototype,  Models  for  Action  Project 
Working  Memo  CTG. MFA-007.  July  1998. 

This  report  presents  the  findings  of  the  CTG  technical  staff  responsible 
for  developing  the  Models  for  Action  prototype.  Within  this  report  we 
examine  the  prototype  objectives  and  functionality,  the  role  of  our 
corporate  partners  in  the  development  process,  and  the  development, 
installation  and  evaluation  of  the  prototype.  We  conclude  with  a  brief 
discussion  of  challenges  and  opportunities  for  similar  development  efforts. 
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Appendix  G.  References  and  related  Web  sites 


Bulletin  for  the  American  Society  for  Information  Science, 

http://www.asis.org/Bulletin/Jun-97/albany.html 

Commission  on  Access  and  Preservation  and  Research  Libraries  Group. 

Preserving  Digital  Information:  Report  of  the  Task  Force  on  Archiving  of 

Digital  Information  (May,  1996). 

http://www.rlg.org/ArchTF/index.html 

Cook,  Terry.  'TPs  10  O’Clock:  Do  You  Know  Where  Your  Data  Are?,” 

MIT's  Technology  Review  (Jan.  1995). 

http :  //WWW.  tech  review,  com/arti  cles/d  ec94/cook.  h t m  I 

Defense  Information  Systems  Agency  (DISA)  -  Records  Management  Page 

http://www.itsi.disa.mil/library.html 

Electronic  Records 

http://www.si.umich.edu/e-recs/ 


GSA  IT  Policy  OnRamp 

http://www.itpolicy.gsa.gov 

HOME  PAGE:  Electronic  Recordkeeping  Reqxiirements 

http://www.sis.pitt.edu/~nhprc/ 

National  Archives  and  Records  Administration  (NARA) 

http://www.nara.gov 

National  Archives  of  Canada 

http://www.archives.ca 

National  Historical  Publications  and  Records  Commission  (NHPRC) 

http://www.nara.gov/nara/nhprc/ 

Preservation  (Digital  Library  SunSITE) 

http://sunsite.Berkeley.EDU/Preservation/ 

Project  Open  Book  Evaluation 

http://www.dlib.org/dlib/february96/yale/02conway.html 

Research  Agenda  for  Cultural  Heritage  on  Information  Networks 

http://www.ahip.getty.edu/agenda 
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The  Center  for  Technology  in  Government 
pursues  new  ways  of  applying  computing  and 
communications  technologies 
to  the  practical  problems  of  information  management 
and  service  delivery  in  the  public  sector. 

The  Center's  program  seeks  to  reduce  the  costs 
and  improve  the  quality  of  government  services, 
reduce  the  risks  of  innovation, 

and  share  the  results  of  its  projects  throughout  the  public  sector. 


The  New  York  State  Archives  and  Records  Administration  (SARA) 
is  part  of  the  New  York  State  Education  Department, 
with  a  broad  mandate  to  provide  guidance  and  services  to 
help  governments  better  manage  their  records,  to  administer  the 
official  State  Archives,  to  regulate  the  disposal  and  selective  preservation  of 
State  and  local  government  records,  and  to  support  activities  that  streng;then 
historical  records  programs  and  encourage  educational  uses  of  historical  records 
throughout  New  York  State.  SARA  is  both  nationally  and  internationally 

recogni2ed  as  a  leading  records  management  and  archival 

organization. 
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